From bburke at redhat.com  Sun Mar  2 17:24:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 02 Mar 2014 17:24:14 -0500
Subject: [keycloak-dev] why authenticate clients?
Message-ID: <5313AF8E.2070809@redhat.com>

A good read:

http://tools.ietf.org/html/rfc6749#section-3.2.1

I was thinking about our current client-secret requirement.  I don't 
think there is any security hole if you are doing the OAuth protocol 
over SSL, you are validating redirect_uris and the client sends its 
"client_id" when obtaining an access token.

* Keycloak server ensures the access code is transmitted to a valid site 
by verifying/validating the redirect_uri sent.
* Since you're using HTTPS, the browser ensures the site is valid by 
checking it's cert.
* If you send the "client_id" when obtaining the access token, the auth 
server can verify that there was no access code substitution.

One of the uses described in 3.2.1 is that it is easier to reset a 
client's credentials than invalidating all the refresh tokens sent to 
it.  I'm not so sure that is true.  If there were a per-app/per-oauth 
client Not-Before setting, we could check this on a refresh request.

Any counter arguments to these assumptions?  I'm going to see if anybody 
on the oauth email list will verify these assumptions.


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

From bburke at redhat.com  Sun Mar  2 17:25:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 02 Mar 2014 17:25:21 -0500
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <5313AF8E.2070809@redhat.com>
References: <5313AF8E.2070809@redhat.com>
Message-ID: <5313AFD1.403@redhat.com>

Ugh sorry, rephrase:

"I don't think there is a need for authenticated clients if you're doing..."

On 3/2/2014 5:24 PM, Bill Burke wrote:
> A good read:
>
> http://tools.ietf.org/html/rfc6749#section-3.2.1
>
> I was thinking about our current client-secret requirement.  I don't
> think there is any security hole if you are doing the OAuth protocol
> over SSL, you are validating redirect_uris and the client sends its
> "client_id" when obtaining an access token.
>
> * Keycloak server ensures the access code is transmitted to a valid site
> by verifying/validating the redirect_uri sent.
> * Since you're using HTTPS, the browser ensures the site is valid by
> checking it's cert.
> * If you send the "client_id" when obtaining the access token, the auth
> server can verify that there was no access code substitution.
>
> One of the uses described in 3.2.1 is that it is easier to reset a
> client's credentials than invalidating all the refresh tokens sent to
> it.  I'm not so sure that is true.  If there were a per-app/per-oauth
> client Not-Before setting, we could check this on a refresh request.
>
> Any counter arguments to these assumptions?  I'm going to see if anybody
> on the oauth email list will verify these assumptions.
>
>

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

From stian at redhat.com  Mon Mar  3 04:33:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 3 Mar 2014 04:33:52 -0500 (EST)
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <5313AFD1.403@redhat.com>
References: <5313AF8E.2070809@redhat.com> <5313AFD1.403@redhat.com>
Message-ID: <1065568678.19504169.1393839232939.JavaMail.zimbra@redhat.com>

Not sure what you're proposing. Are you saying that we shouldn't authenticate clients at all?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 2 March, 2014 10:25:21 PM
> Subject: Re: [keycloak-dev] why authenticate clients?
> 
> Ugh sorry, rephrase:
> 
> "I don't think there is a need for authenticated clients if you're doing..."
> 
> On 3/2/2014 5:24 PM, Bill Burke wrote:
> > A good read:
> >
> > http://tools.ietf.org/html/rfc6749#section-3.2.1
> >
> > I was thinking about our current client-secret requirement.  I don't
> > think there is any security hole if you are doing the OAuth protocol
> > over SSL, you are validating redirect_uris and the client sends its
> > "client_id" when obtaining an access token.
> >
> > * Keycloak server ensures the access code is transmitted to a valid site
> > by verifying/validating the redirect_uri sent.
> > * Since you're using HTTPS, the browser ensures the site is valid by
> > checking it's cert.
> > * If you send the "client_id" when obtaining the access token, the auth
> > server can verify that there was no access code substitution.
> >
> > One of the uses described in 3.2.1 is that it is easier to reset a
> > client's credentials than invalidating all the refresh tokens sent to
> > it.  I'm not so sure that is true.  If there were a per-app/per-oauth
> > client Not-Before setting, we could check this on a refresh request.
> >
> > Any counter arguments to these assumptions?  I'm going to see if anybody
> > on the oauth email list will verify these assumptions.
> >
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Mon Mar  3 04:46:22 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 03 Mar 2014 10:46:22 +0100
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <5313AF8E.2070809@redhat.com>
References: <5313AF8E.2070809@redhat.com>
Message-ID: <53144F6E.1050806@redhat.com>

On 2.3.2014 23:24, Bill Burke wrote:
> A good read:
>
> http://tools.ietf.org/html/rfc6749#section-3.2.1
>
> I was thinking about our current client-secret requirement.  I don't
> think there is any security hole if you are doing the OAuth protocol
> over SSL, you are validating redirect_uris and the client sends its
> "client_id" when obtaining an access token.
>
> * Keycloak server ensures the access code is transmitted to a valid site
> by verifying/validating the redirect_uri sent.
I am not sure if protection based on redirect_uris could be considered 
secure. For example if Keycloak has application with redirect_uri 
"http://www.redhat.com/something" then nothing prevents me from adding 
"www.redhat.com" into my /etc/hosts and run application on my machine 
bind to "www.redhat.com", which will communicate with Keycloak. It seems 
that Keycloak won't be able to recognize if request really comes from 
valid "www.redhat.com" or from my fake host.

Marek
> * Since you're using HTTPS, the browser ensures the site is valid by
> checking it's cert.
> * If you send the "client_id" when obtaining the access token, the auth
> server can verify that there was no access code substitution.
>
> One of the uses described in 3.2.1 is that it is easier to reset a
> client's credentials than invalidating all the refresh tokens sent to
> it.  I'm not so sure that is true.  If there were a per-app/per-oauth
> client Not-Before setting, we could check this on a refresh request.
>
> Any counter arguments to these assumptions?  I'm going to see if anybody
> on the oauth email list will verify these assumptions.
>
>


From stian at redhat.com  Mon Mar  3 04:53:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 3 Mar 2014 04:53:22 -0500 (EST)
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <53144F6E.1050806@redhat.com>
References: <5313AF8E.2070809@redhat.com> <53144F6E.1050806@redhat.com>
Message-ID: <997285748.19524773.1393840402391.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, 3 March, 2014 9:46:22 AM
> Subject: Re: [keycloak-dev] why authenticate clients?
> 
> On 2.3.2014 23:24, Bill Burke wrote:
> > A good read:
> >
> > http://tools.ietf.org/html/rfc6749#section-3.2.1
> >
> > I was thinking about our current client-secret requirement.  I don't
> > think there is any security hole if you are doing the OAuth protocol
> > over SSL, you are validating redirect_uris and the client sends its
> > "client_id" when obtaining an access token.
> >
> > * Keycloak server ensures the access code is transmitted to a valid site
> > by verifying/validating the redirect_uri sent.
> I am not sure if protection based on redirect_uris could be considered
> secure. For example if Keycloak has application with redirect_uri
> "http://www.redhat.com/something" then nothing prevents me from adding
> "www.redhat.com" into my /etc/hosts and run application on my machine
> bind to "www.redhat.com", which will communicate with Keycloak. It seems
> that Keycloak won't be able to recognize if request really comes from
> valid "www.redhat.com" or from my fake host.

For public clients protecting based on redirect_uri is the only option, as public clients = public secret. 

SSL certificates will take care of the example your giving though. If you try to visit https://www.redhat.com and a malicious DNS (or hosts file) swaps that for another site the certificate won't be valid for the domain (unless you've got a compromised certificate authority listed in your browser or use iOS ;)).

> 
> Marek
> > * Since you're using HTTPS, the browser ensures the site is valid by
> > checking it's cert.
> > * If you send the "client_id" when obtaining the access token, the auth
> > server can verify that there was no access code substitution.
> >
> > One of the uses described in 3.2.1 is that it is easier to reset a
> > client's credentials than invalidating all the refresh tokens sent to
> > it.  I'm not so sure that is true.  If there were a per-app/per-oauth
> > client Not-Before setting, we could check this on a refresh request.
> >
> > Any counter arguments to these assumptions?  I'm going to see if anybody
> > on the oauth email list will verify these assumptions.
> >
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Mon Mar  3 05:14:13 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 03 Mar 2014 11:14:13 +0100
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <997285748.19524773.1393840402391.JavaMail.zimbra@redhat.com>
References: <5313AF8E.2070809@redhat.com> <53144F6E.1050806@redhat.com>
	<997285748.19524773.1393840402391.JavaMail.zimbra@redhat.com>
Message-ID: <531455F5.1010702@redhat.com>

On 3.3.2014 10:53, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Monday, 3 March, 2014 9:46:22 AM
>> Subject: Re: [keycloak-dev] why authenticate clients?
>>
>> On 2.3.2014 23:24, Bill Burke wrote:
>>> A good read:
>>>
>>> http://tools.ietf.org/html/rfc6749#section-3.2.1
>>>
>>> I was thinking about our current client-secret requirement.  I don't
>>> think there is any security hole if you are doing the OAuth protocol
>>> over SSL, you are validating redirect_uris and the client sends its
>>> "client_id" when obtaining an access token.
>>>
>>> * Keycloak server ensures the access code is transmitted to a valid site
>>> by verifying/validating the redirect_uri sent.
>> I am not sure if protection based on redirect_uris could be considered
>> secure. For example if Keycloak has application with redirect_uri
>> "http://www.redhat.com/something" then nothing prevents me from adding
>> "www.redhat.com" into my /etc/hosts and run application on my machine
>> bind to "www.redhat.com", which will communicate with Keycloak. It seems
>> that Keycloak won't be able to recognize if request really comes from
>> valid "www.redhat.com" or from my fake host.
> For public clients protecting based on redirect_uri is the only option, as public clients = public secret.
>
> SSL certificates will take care of the example your giving though. If you try to visit https://www.redhat.com and a malicious DNS (or hosts file) swaps that for another site the certificate won't be valid for the domain (unless you've got a compromised certificate authority listed in your browser or use iOS ;)).
yes, protection based on SSL should help. What I mean is that protection 
based just on redirect_uri is not sufficient and can't be considered as 
any real security protection without using anything else (like SSL).

Marek
>
>> Marek
>>> * Since you're using HTTPS, the browser ensures the site is valid by
>>> checking it's cert.
>>> * If you send the "client_id" when obtaining the access token, the auth
>>> server can verify that there was no access code substitution.
>>>
>>> One of the uses described in 3.2.1 is that it is easier to reset a
>>> client's credentials than invalidating all the refresh tokens sent to
>>> it.  I'm not so sure that is true.  If there were a per-app/per-oauth
>>> client Not-Before setting, we could check this on a refresh request.
>>>
>>> Any counter arguments to these assumptions?  I'm going to see if anybody
>>> on the oauth email list will verify these assumptions.
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Mon Mar  3 09:52:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 03 Mar 2014 09:52:25 -0500
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <1065568678.19504169.1393839232939.JavaMail.zimbra@redhat.com>
References: <5313AF8E.2070809@redhat.com> <5313AFD1.403@redhat.com>
	<1065568678.19504169.1393839232939.JavaMail.zimbra@redhat.com>
Message-ID: <53149729.6040500@redhat.com>



On 3/3/2014 4:33 AM, Stian Thorgersen wrote:
> Not sure what you're proposing. Are you saying that we shouldn't authenticate clients at all?
>

Not proposing anything.  Our pure-javascript/html5 adapter is a public 
client.  I'm just saying that in that case, its just as secure as a 
confidential client is you use SSL.  It also helps in cases where its 
difficult to distribute/store client secrets, i.e. in the multi-tenant 
case that Travis (a keycloak user) has been talking about on the user list.

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

From stian at redhat.com  Mon Mar  3 10:06:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 3 Mar 2014 10:06:14 -0500 (EST)
Subject: [keycloak-dev] Support for installed applications
In-Reply-To: <1880745203.19683904.1393858847208.JavaMail.zimbra@redhat.com>
Message-ID: <1651381655.19688482.1393859174095.JavaMail.zimbra@redhat.com>

For installed applications Google, and at least some others, provide two special redirect_uris:

* urn:ietf:wg:oauth:2.0:oob
* http://localhost

The first (urn:ietf:wg:oauth:2.0:oob) redirects to a special page on the auth server which displays the code in the browser title and in a textarea. See https://developers.google.com/accounts/images/installedresult.png for an example. This can be used in the case where an installed application is not able to start a "temporary" browser to list for requests on localhost. Or in the case where you need the user to manually copy/paste the code to the app.

The second allows using localhost with any port. This is the recommended approach as the application can start a "temporary" browser on any free port to listen for a request to retrieve the code.

I'm working adding these to Keycloak. This is needed at the moment to support Cordova applications, but will also be useful for anyone that wants to do other types of installed applications (for example a CLI).

From bburke at redhat.com  Mon Mar  3 10:28:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 03 Mar 2014 10:28:58 -0500
Subject: [keycloak-dev] Release March 13th
Message-ID: <53149FBA.4030006@redhat.com>

We have enough features for alpha 3 (refresh tokens, realm admin roles, 
revocation, and session/login mgmt, and hopefully a bare-bones 
mult-tenant adapter).  I'd like to release March 13th.  Have everything 
in by March 11th for testing and building.

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

From bburke at redhat.com  Mon Mar  3 17:45:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 03 Mar 2014 17:45:26 -0500
Subject: [keycloak-dev] revocation is in
Message-ID: <53150606.8010208@redhat.com>

You can set up a Not Before policy at the realm or client level.  You 
have the option to PUSH this value to the client adapters that have a 
admin url set up.  Not Before policy is also piggybacked with 
AccessTokenResponse too.  Adapters recheck the not before policy before 
each request and will force a re-auth if the token is stale.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Mar  4 09:56:36 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 4 Mar 2014 09:56:36 -0500 (EST)
Subject: [keycloak-dev] ng-disabled no longer works
In-Reply-To: <5310F093.8020802@redhat.com>
References: <5310F093.8020802@redhat.com>
Message-ID: <1629150005.20427173.1393944996325.JavaMail.zimbra@redhat.com>

Yes, because I've messed it up with the read-only forms.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 28 February, 2014 8:24:51 PM
> Subject: [keycloak-dev] ng-disabled no longer works
> 
> Can you think of any reason ng-disabled no longer works?  i.e. on
> application-credentials.html page?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Mar  5 15:09:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Mar 2014 15:09:10 -0500
Subject: [keycloak-dev] session mgmt in
Message-ID: <53178466.5030605@redhat.com>

You can now view open session stats for all applications on one page. 
You can then drill down and see what users have sessions open on the 
application.  You can also view which applicatins a user has open 
sessions on.  From all these different pages you can perform remote logouts.

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

From bburke at redhat.com  Wed Mar  5 18:04:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Mar 2014 18:04:46 -0500
Subject: [keycloak-dev] discontinuing scope param
Message-ID: <5317AD8E.7090001@redhat.com>

OpenID Connect has its own format for the scope param that interferes 
with ours.  I'm discontinuing our support for it.  Scope param will just 
be ignored now.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From daniel at passos.me  Wed Mar  5 20:15:42 2014
From: daniel at passos.me (Daniel Passos)
Date: Wed, 5 Mar 2014 22:15:42 -0300
Subject: [keycloak-dev] 1.0 Final roadmap
Message-ID: <etPan.5317cc3e.643c9869.843e@Daniels-MacBook-Air.local>

Hi?Stian,

We have been playing with Keycloak and we plan to release integration bits on agdroid 1.5.

I've created an issue[1] for it and linked it with KEYCLOAK-306

[1] https://issues.jboss.org/browse/AGDROID-222

--?
Daniel Passos

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

From bburke at redhat.com  Wed Mar  5 20:29:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 05 Mar 2014 20:29:57 -0500
Subject: [keycloak-dev] public clients and wildcard redirects
Message-ID: <5317CF95.9040406@redhat.com>

Added support for public clients and App/OAuth Client wildcard redirect 
urls.

* Login will fail if you have a public client and no redirect url configured
* For confidential clients you can now use basic auth or form based 
authentication based on OAuth 2 spec.


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

From stian at redhat.com  Thu Mar  6 04:09:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 04:09:56 -0500 (EST)
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <5317AD8E.7090001@redhat.com>
References: <5317AD8E.7090001@redhat.com>
Message-ID: <1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>

Are we adding (or have we already added) the OpenID Connect scope param?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 5 March, 2014 11:04:46 PM
> Subject: [keycloak-dev] discontinuing scope param
> 
> OpenID Connect has its own format for the scope param that interferes
> with ours.  I'm discontinuing our support for it.  Scope param will just
> be ignored now.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Mar  6 04:14:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 04:14:03 -0500 (EST)
Subject: [keycloak-dev] 1.0 Final roadmap
In-Reply-To: <etPan.5317cc3e.643c9869.843e@Daniels-MacBook-Air.local>
References: <etPan.5317cc3e.643c9869.843e@Daniels-MacBook-Air.local>
Message-ID: <193066212.21684090.1394097243035.JavaMail.zimbra@redhat.com>

Hi Daniel,

Awesome :)

Let me know if you have any problems with Keycloak, or any questions at all.

Cheers,
Stian

----- Original Message -----
> From: "Daniel Passos" <daniel at passos.me>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 1:15:42 AM
> Subject: Re: [keycloak-dev] 1.0 Final roadmap
> 
> Hi Stian,
> 
> We have been playing with Keycloak and we plan to release integration bits on
> agdroid 1.5.
> 
> I've created an issue[1] for it and linked it with KEYCLOAK-306
> 
> [1] https://issues.jboss.org/browse/AGDROID-222
> 
> --
> Daniel Passos
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Mar  6 07:05:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 07:05:06 -0500 (EST)
Subject: [keycloak-dev] public clients and wildcard redirects
In-Reply-To: <5317CF95.9040406@redhat.com>
References: <5317CF95.9040406@redhat.com>
Message-ID: <1990624955.21805715.1394107506445.JavaMail.zimbra@redhat.com>

Nice :)

Instead of having bearer on/off and public on/off, would it be better to have an 'application type' drop-down (standard, bearer-only, public)?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 1:29:57 AM
> Subject: [keycloak-dev] public clients and wildcard redirects
> 
> Added support for public clients and App/OAuth Client wildcard redirect
> urls.
> 
> * Login will fail if you have a public client and no redirect url configured
> * For confidential clients you can now use basic auth or form based
> authentication based on OAuth 2 spec.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Mar  6 07:15:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 07:15:05 -0500 (EST)
Subject: [keycloak-dev] Support for installed applications added (including
	example)
In-Reply-To: <375844374.21808897.1394107781658.JavaMail.zimbra@redhat.com>
Message-ID: <1119534784.21815064.1394108105542.JavaMail.zimbra@redhat.com>

Support for installed applications in form of two special redirect uris (urn:ietf:wg:oauth:2.0:oob and http://localhost) has been added.

There's also a basic example. To try it out start the server as normal, create an app for it (mark it as public). Download the keycloak.json file. Then run:

# mvn -pl examples/demo-template/customer-app-cli install exec:java -Dexec.args="<path to keycloak.json>"

You can then run different commands to try it out. It has two different ways to login the user:

* login-desktop: this opens a ServerSocket on a local port, opens the login url in the browser, after login the ServerSocket is used to retrieve the code
* login-manual: this uses the 'urn:ietf:wg:oauth:2.0:oob' redirect to display the code in the browser and the user has to manually copy/paste this into the application

From bburke at redhat.com  Thu Mar  6 08:51:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 08:51:47 -0500
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>
References: <5317AD8E.7090001@redhat.com>
	<1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>
Message-ID: <53187D73.1020006@redhat.com>

Nah, just going to ignore the scope param.  We'll just ignore what pure 
openid connect clients send in the scope param.

On 3/6/2014 4:09 AM, Stian Thorgersen wrote:
> Are we adding (or have we already added) the OpenID Connect scope param?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 5 March, 2014 11:04:46 PM
>> Subject: [keycloak-dev] discontinuing scope param
>>
>> OpenID Connect has its own format for the scope param that interferes
>> with ours.  I'm discontinuing our support for it.  Scope param will just
>> be ignored now.
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Thu Mar  6 08:53:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 08:53:46 -0500
Subject: [keycloak-dev] public clients and wildcard redirects
In-Reply-To: <1990624955.21805715.1394107506445.JavaMail.zimbra@redhat.com>
References: <5317CF95.9040406@redhat.com>
	<1990624955.21805715.1394107506445.JavaMail.zimbra@redhat.com>
Message-ID: <53187DEA.3030609@redhat.com>

that sounds better.

On 3/6/2014 7:05 AM, Stian Thorgersen wrote:
> Nice :)
>
> Instead of having bearer on/off and public on/off, would it be better to have an 'application type' drop-down (standard, bearer-only, public)?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 6 March, 2014 1:29:57 AM
>> Subject: [keycloak-dev] public clients and wildcard redirects
>>
>> Added support for public clients and App/OAuth Client wildcard redirect
>> urls.
>>
>> * Login will fail if you have a public client and no redirect url configured
>> * For confidential clients you can now use basic auth or form based
>> authentication based on OAuth 2 spec.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Thu Mar  6 09:10:07 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 09:10:07 -0500 (EST)
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <53187D73.1020006@redhat.com>
References: <5317AD8E.7090001@redhat.com>
	<1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>
	<53187D73.1020006@redhat.com>
Message-ID: <342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>

We need a scope parameter. It's best practice for an app to ask for the minimum scope possible, and that may vary not only on the client.

For example a gallery application could initially only want a users basic profile and permissions to view pictures. Only if users choose to use the edit feature would it ask for edit permissions.

It is also common that OAuth provider have this. For example in the Google Cloud Console you can configure what an application is allowed to ask for, but you are also required to include a scope parameter. I don't think the scope parameter needs to be required, but we should add support for it.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 1:51:47 PM
> Subject: Re: [keycloak-dev] discontinuing scope param
> 
> Nah, just going to ignore the scope param.  We'll just ignore what pure
> openid connect clients send in the scope param.
> 
> On 3/6/2014 4:09 AM, Stian Thorgersen wrote:
> > Are we adding (or have we already added) the OpenID Connect scope param?
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 5 March, 2014 11:04:46 PM
> >> Subject: [keycloak-dev] discontinuing scope param
> >>
> >> OpenID Connect has its own format for the scope param that interferes
> >> with ours.  I'm discontinuing our support for it.  Scope param will just
> >> be ignored now.
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Mar  6 09:47:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 09:47:36 -0500
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>
References: <5317AD8E.7090001@redhat.com>
	<1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>
	<53187D73.1020006@redhat.com>
	<342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>
Message-ID: <53188A88.7010900@redhat.com>

This is really just an optimization.

On 3/6/2014 9:10 AM, Stian Thorgersen wrote:
> We need a scope parameter. It's best practice for an app to ask for the minimum scope possible, and that may vary not only on the client.
>
> For example a gallery application could initially only want a users basic profile and permissions to view pictures. Only if users choose to use the edit feature would it ask for edit permissions.
>
> It is also common that OAuth provider have this. For example in the Google Cloud Console you can configure what an application is allowed to ask for, but you are also required to include a scope parameter. I don't think the scope parameter needs to be required, but we should add support for it.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 6 March, 2014 1:51:47 PM
>> Subject: Re: [keycloak-dev] discontinuing scope param
>>
>> Nah, just going to ignore the scope param.  We'll just ignore what pure
>> openid connect clients send in the scope param.
>>
>> On 3/6/2014 4:09 AM, Stian Thorgersen wrote:
>>> Are we adding (or have we already added) the OpenID Connect scope param?
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 5 March, 2014 11:04:46 PM
>>>> Subject: [keycloak-dev] discontinuing scope param
>>>>
>>>> OpenID Connect has its own format for the scope param that interferes
>>>> with ours.  I'm discontinuing our support for it.  Scope param will just
>>>> be ignored now.
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

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

From stian at redhat.com  Thu Mar  6 10:01:35 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 10:01:35 -0500 (EST)
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <53188A88.7010900@redhat.com>
References: <5317AD8E.7090001@redhat.com>
	<1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>
	<53187D73.1020006@redhat.com>
	<342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>
	<53188A88.7010900@redhat.com>
Message-ID: <1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>

For applications yes, this is just a "performance" optimization, and it would probably never be used.

For clients it's important. Users may choose not to use an application if it requests to many permissions. In my previous example you may be happy with a gallery application viewing your pictures, but if it requests to edit your pictures as well and you're not happy with it both you as a user and the developer of the application loose out.

Have a look at http://www.youtube.com/watch?v=vFsxQHSSkRs it explains it all in 1 min

It would also be cool if we added a way to mark parts of the scope as optional. For example in the above example the gallery app could say it requires to view the profile and view pictures, but only optionally edit pictures. On the grant page there could be a checkbox next to optional permissions that let's a user allow/disallow that specific permission.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 2:47:36 PM
> Subject: Re: [keycloak-dev] discontinuing scope param
> 
> This is really just an optimization.
> 
> On 3/6/2014 9:10 AM, Stian Thorgersen wrote:
> > We need a scope parameter. It's best practice for an app to ask for the
> > minimum scope possible, and that may vary not only on the client.
> >
> > For example a gallery application could initially only want a users basic
> > profile and permissions to view pictures. Only if users choose to use the
> > edit feature would it ask for edit permissions.
> >
> > It is also common that OAuth provider have this. For example in the Google
> > Cloud Console you can configure what an application is allowed to ask for,
> > but you are also required to include a scope parameter. I don't think the
> > scope parameter needs to be required, but we should add support for it.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 6 March, 2014 1:51:47 PM
> >> Subject: Re: [keycloak-dev] discontinuing scope param
> >>
> >> Nah, just going to ignore the scope param.  We'll just ignore what pure
> >> openid connect clients send in the scope param.
> >>
> >> On 3/6/2014 4:09 AM, Stian Thorgersen wrote:
> >>> Are we adding (or have we already added) the OpenID Connect scope param?
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, 5 March, 2014 11:04:46 PM
> >>>> Subject: [keycloak-dev] discontinuing scope param
> >>>>
> >>>> OpenID Connect has its own format for the scope param that interferes
> >>>> with ours.  I'm discontinuing our support for it.  Scope param will just
> >>>> be ignored now.
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Mar  6 10:14:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 10:14:16 -0500
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>
References: <5317AD8E.7090001@redhat.com>
	<1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>
	<53187D73.1020006@redhat.com>
	<342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>
	<53188A88.7010900@redhat.com>
	<1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>
Message-ID: <531890C8.9080401@redhat.com>



On 3/6/2014 10:01 AM, Stian Thorgersen wrote:
> For applications yes, this is just a "performance" optimization, and it would probably never be used.
>
> For clients it's important. Users may choose not to use an application if it requests to many permissions. In my previous example you may be happy with a gallery application viewing your pictures, but if it requests to edit your pictures as well and you're not happy with it both you as a user and the developer of the application loose out.
>
> Have a look at http://www.youtube.com/watch?v=vFsxQHSSkRs it explains it all in 1 min
>
> It would also be cool if we added a way to mark parts of the scope as optional. For example in the above example the gallery app could say it requires to view the profile and view pictures, but only optionally edit pictures. On the grant page there could be a checkbox next to optional permissions that let's a user allow/disallow that specific permission.
>

I'm still removing what we currently have until a new param format is 
decided on and implemented that fits in openid connect scope param 
format constraints.  This scope param support I'm removing isn't 
documented anyways, so I doubt anybody has tried it out.

BTW,  I also wanted to add metadata to roles on whether it should be 
displayed in a grant page or not.


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

From stian at redhat.com  Thu Mar  6 10:24:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 10:24:27 -0500 (EST)
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <531890C8.9080401@redhat.com>
References: <5317AD8E.7090001@redhat.com>
	<1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>
	<53187D73.1020006@redhat.com>
	<342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>
	<53188A88.7010900@redhat.com>
	<1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>
	<531890C8.9080401@redhat.com>
Message-ID: <498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 3:14:16 PM
> Subject: Re: [keycloak-dev] discontinuing scope param
> 
> 
> 
> On 3/6/2014 10:01 AM, Stian Thorgersen wrote:
> > For applications yes, this is just a "performance" optimization, and it
> > would probably never be used.
> >
> > For clients it's important. Users may choose not to use an application if
> > it requests to many permissions. In my previous example you may be happy
> > with a gallery application viewing your pictures, but if it requests to
> > edit your pictures as well and you're not happy with it both you as a user
> > and the developer of the application loose out.
> >
> > Have a look at http://www.youtube.com/watch?v=vFsxQHSSkRs it explains it
> > all in 1 min
> >
> > It would also be cool if we added a way to mark parts of the scope as
> > optional. For example in the above example the gallery app could say it
> > requires to view the profile and view pictures, but only optionally edit
> > pictures. On the grant page there could be a checkbox next to optional
> > permissions that let's a user allow/disallow that specific permission.
> >
> 
> I'm still removing what we currently have until a new param format is
> decided on and implemented that fits in openid connect scope param
> format constraints.  This scope param support I'm removing isn't
> documented anyways, so I doubt anybody has tried it out.

That's fine, I can create a JIRA issue to add support for it. I thought you where proposing to remove it and never add it back ;)

Unless someone explicitly asks for it I think we're fine with leaving it until later

> 
> BTW,  I also wanted to add metadata to roles on whether it should be
> displayed in a grant page or not.

That's a nice feature, but I can't come up with a use-case for it. Do you have one in mind?

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

From bburke at redhat.com  Thu Mar  6 10:40:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 10:40:52 -0500
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>
References: <5317AD8E.7090001@redhat.com>
	<1454730111.21681994.1394096996189.JavaMail.zimbra@redhat.com>
	<53187D73.1020006@redhat.com>
	<342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>
	<53188A88.7010900@redhat.com>
	<1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>
	<531890C8.9080401@redhat.com>
	<498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>
Message-ID: <53189704.2000409@redhat.com>



On 3/6/2014 10:24 AM, Stian Thorgersen wrote:
>>
>> BTW,  I also wanted to add metadata to roles on whether it should be
>> displayed in a grant page or not.
>
> That's a nice feature, but I can't come up with a use-case for it. Do you have one in mind?

Same usecase as you mentioned earlier.  To reduce amount of things the 
client is asking permission to do on the grant page.

For example, you might have a composite role "Users" and only want to 
show that role on the grant page, not its children.  Right now, all 
roles are showed.


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

From bburke at redhat.com  Thu Mar  6 10:44:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 10:44:07 -0500
Subject: [keycloak-dev] please update JIRA for alpha 3
Message-ID: <531897C7.4000500@redhat.com>

Please close alpha 3 issues you have completed.  Defer others that you 
will not get done by next Tuesday.

Thanks,

Bill

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

From stian at redhat.com  Thu Mar  6 10:44:25 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 10:44:25 -0500 (EST)
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <53189704.2000409@redhat.com>
References: <5317AD8E.7090001@redhat.com> <53187D73.1020006@redhat.com>
	<342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>
	<53188A88.7010900@redhat.com>
	<1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>
	<531890C8.9080401@redhat.com>
	<498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>
	<53189704.2000409@redhat.com>
Message-ID: <1362847938.22054379.1394120665558.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 3:40:52 PM
> Subject: Re: [keycloak-dev] discontinuing scope param
> 
> 
> 
> On 3/6/2014 10:24 AM, Stian Thorgersen wrote:
> >>
> >> BTW,  I also wanted to add metadata to roles on whether it should be
> >> displayed in a grant page or not.
> >
> > That's a nice feature, but I can't come up with a use-case for it. Do you
> > have one in mind?
> 
> Same usecase as you mentioned earlier.  To reduce amount of things the
> client is asking permission to do on the grant page.

I assume it would be used for a way to have "implicit" permissions granted to a client, but I couldn't think of anything that a client should be allowed to do without requestion access

> 
> For example, you might have a composite role "Users" and only want to
> show that role on the grant page, not its children.  Right now, all
> roles are showed.

What if a client has a scope on the children and not the composite? Would it display the children then?

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

From bburke at redhat.com  Thu Mar  6 10:49:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 10:49:48 -0500
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <1362847938.22054379.1394120665558.JavaMail.zimbra@redhat.com>
References: <5317AD8E.7090001@redhat.com> <53187D73.1020006@redhat.com>
	<342846800.21951381.1394115007973.JavaMail.zimbra@redhat.com>
	<53188A88.7010900@redhat.com>
	<1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>
	<531890C8.9080401@redhat.com>
	<498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>
	<53189704.2000409@redhat.com>
	<1362847938.22054379.1394120665558.JavaMail.zimbra@redhat.com>
Message-ID: <5318991C.7060401@redhat.com>



On 3/6/2014 10:44 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 6 March, 2014 3:40:52 PM
>> Subject: Re: [keycloak-dev] discontinuing scope param
>>
>>
>>
>> On 3/6/2014 10:24 AM, Stian Thorgersen wrote:
>>>>
>>>> BTW,  I also wanted to add metadata to roles on whether it should be
>>>> displayed in a grant page or not.
>>>
>>> That's a nice feature, but I can't come up with a use-case for it. Do you
>>> have one in mind?
>>
>> Same usecase as you mentioned earlier.  To reduce amount of things the
>> client is asking permission to do on the grant page.
>
> I assume it would be used for a way to have "implicit" permissions granted to a client, but I couldn't think of anything that a client should be allowed to do without requestion access
>
>>
>> For example, you might have a composite role "Users" and only want to
>> show that role on the grant page, not its children.  Right now, all
>> roles are showed.
>
> What if a client has a scope on the children and not the composite? Would it display the children then?
>

Right now, requested roles are calculated fully based on the client's 
scope and the user role mappings.  I thought maybe this list would be 
iterated on and roles removed from the grant page based on whether or 
not the role was marked as something displayable.  Maybe it wouldn't be 
used much, but it sure would be simple to add.

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

From stian at redhat.com  Thu Mar  6 10:56:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 10:56:15 -0500 (EST)
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <5318991C.7060401@redhat.com>
References: <5317AD8E.7090001@redhat.com> <53188A88.7010900@redhat.com>
	<1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>
	<531890C8.9080401@redhat.com>
	<498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>
	<53189704.2000409@redhat.com>
	<1362847938.22054379.1394120665558.JavaMail.zimbra@redhat.com>
	<5318991C.7060401@redhat.com>
Message-ID: <99650028.22064551.1394121375742.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 3:49:48 PM
> Subject: Re: [keycloak-dev] discontinuing scope param
> 
> 
> 
> On 3/6/2014 10:44 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 6 March, 2014 3:40:52 PM
> >> Subject: Re: [keycloak-dev] discontinuing scope param
> >>
> >>
> >>
> >> On 3/6/2014 10:24 AM, Stian Thorgersen wrote:
> >>>>
> >>>> BTW,  I also wanted to add metadata to roles on whether it should be
> >>>> displayed in a grant page or not.
> >>>
> >>> That's a nice feature, but I can't come up with a use-case for it. Do you
> >>> have one in mind?
> >>
> >> Same usecase as you mentioned earlier.  To reduce amount of things the
> >> client is asking permission to do on the grant page.
> >
> > I assume it would be used for a way to have "implicit" permissions granted
> > to a client, but I couldn't think of anything that a client should be
> > allowed to do without requestion access
> >
> >>
> >> For example, you might have a composite role "Users" and only want to
> >> show that role on the grant page, not its children.  Right now, all
> >> roles are showed.
> >
> > What if a client has a scope on the children and not the composite? Would
> > it display the children then?
> >
> 
> Right now, requested roles are calculated fully based on the client's
> scope and the user role mappings.  I thought maybe this list would be
> iterated on and roles removed from the grant page based on whether or
> not the role was marked as something displayable.  Maybe it wouldn't be
> used much, but it sure would be simple to add.

My questions still stands, would it not just be a mechanism for a client to obtain permissions without the users knowledge?

With regards to the composite roles example you gave I think it would be nice to be able to show only the composite, but I think it should be done so that if a client requests the "simple" roles not the composite they are still shown (so just marking a specific role as not-show wouldn't work here). Maybe an option on composite roles (show all, show composite, show children)?

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

From bburke at redhat.com  Thu Mar  6 10:58:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 10:58:03 -0500
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <99650028.22064551.1394121375742.JavaMail.zimbra@redhat.com>
References: <5317AD8E.7090001@redhat.com> <53188A88.7010900@redhat.com>
	<1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>
	<531890C8.9080401@redhat.com>
	<498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>
	<53189704.2000409@redhat.com>
	<1362847938.22054379.1394120665558.JavaMail.zimbra@redhat.com>
	<5318991C.7060401@redhat.com>
	<99650028.22064551.1394121375742.JavaMail.zimbra@redhat.com>
Message-ID: <53189B0B.9050306@redhat.com>



On 3/6/2014 10:56 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 6 March, 2014 3:49:48 PM
>> Subject: Re: [keycloak-dev] discontinuing scope param
>>
>>
>>
>> On 3/6/2014 10:44 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 6 March, 2014 3:40:52 PM
>>>> Subject: Re: [keycloak-dev] discontinuing scope param
>>>>
>>>>
>>>>
>>>> On 3/6/2014 10:24 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>> BTW,  I also wanted to add metadata to roles on whether it should be
>>>>>> displayed in a grant page or not.
>>>>>
>>>>> That's a nice feature, but I can't come up with a use-case for it. Do you
>>>>> have one in mind?
>>>>
>>>> Same usecase as you mentioned earlier.  To reduce amount of things the
>>>> client is asking permission to do on the grant page.
>>>
>>> I assume it would be used for a way to have "implicit" permissions granted
>>> to a client, but I couldn't think of anything that a client should be
>>> allowed to do without requestion access
>>>
>>>>
>>>> For example, you might have a composite role "Users" and only want to
>>>> show that role on the grant page, not its children.  Right now, all
>>>> roles are showed.
>>>
>>> What if a client has a scope on the children and not the composite? Would
>>> it display the children then?
>>>
>>
>> Right now, requested roles are calculated fully based on the client's
>> scope and the user role mappings.  I thought maybe this list would be
>> iterated on and roles removed from the grant page based on whether or
>> not the role was marked as something displayable.  Maybe it wouldn't be
>> used much, but it sure would be simple to add.
>
> My questions still stands, would it not just be a mechanism for a client to obtain permissions without the users knowledge?
>

Yes.  Some people might like to ignore privacy policies ;)

> With regards to the composite roles example you gave I think it would be nice to be able to show only the composite, but I think it should be done so that if a client requests the "simple" roles not the composite they are still shown (so just marking a specific role as not-show wouldn't work here). Maybe an option on composite roles (show all, show composite, show children)?
>


That sounds good.

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

From stian at redhat.com  Thu Mar  6 11:07:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 11:07:44 -0500 (EST)
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <53189B0B.9050306@redhat.com>
References: <5317AD8E.7090001@redhat.com> <531890C8.9080401@redhat.com>
	<498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>
	<53189704.2000409@redhat.com>
	<1362847938.22054379.1394120665558.JavaMail.zimbra@redhat.com>
	<5318991C.7060401@redhat.com>
	<99650028.22064551.1394121375742.JavaMail.zimbra@redhat.com>
	<53189B0B.9050306@redhat.com>
Message-ID: <281464321.22094074.1394122064790.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 3:58:03 PM
> Subject: Re: [keycloak-dev] discontinuing scope param
> 
> 
> 
> On 3/6/2014 10:56 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 6 March, 2014 3:49:48 PM
> >> Subject: Re: [keycloak-dev] discontinuing scope param
> >>
> >>
> >>
> >> On 3/6/2014 10:44 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 6 March, 2014 3:40:52 PM
> >>>> Subject: Re: [keycloak-dev] discontinuing scope param
> >>>>
> >>>>
> >>>>
> >>>> On 3/6/2014 10:24 AM, Stian Thorgersen wrote:
> >>>>>>
> >>>>>> BTW,  I also wanted to add metadata to roles on whether it should be
> >>>>>> displayed in a grant page or not.
> >>>>>
> >>>>> That's a nice feature, but I can't come up with a use-case for it. Do
> >>>>> you
> >>>>> have one in mind?
> >>>>
> >>>> Same usecase as you mentioned earlier.  To reduce amount of things the
> >>>> client is asking permission to do on the grant page.
> >>>
> >>> I assume it would be used for a way to have "implicit" permissions
> >>> granted
> >>> to a client, but I couldn't think of anything that a client should be
> >>> allowed to do without requestion access
> >>>
> >>>>
> >>>> For example, you might have a composite role "Users" and only want to
> >>>> show that role on the grant page, not its children.  Right now, all
> >>>> roles are showed.
> >>>
> >>> What if a client has a scope on the children and not the composite? Would
> >>> it display the children then?
> >>>
> >>
> >> Right now, requested roles are calculated fully based on the client's
> >> scope and the user role mappings.  I thought maybe this list would be
> >> iterated on and roles removed from the grant page based on whether or
> >> not the role was marked as something displayable.  Maybe it wouldn't be
> >> used much, but it sure would be simple to add.
> >
> > My questions still stands, would it not just be a mechanism for a client to
> > obtain permissions without the users knowledge?
> >
> 
> Yes.  Some people might like to ignore privacy policies ;)

Actually, as it would require manage-realm and/or manage-applications permissions it's probably fine. Anyone with those permissions could just go and create an application instead of a client in the first place, and just bypass the grant page altogether.

> 
> > With regards to the composite roles example you gave I think it would be
> > nice to be able to show only the composite, but I think it should be done
> > so that if a client requests the "simple" roles not the composite they are
> > still shown (so just marking a specific role as not-show wouldn't work
> > here). Maybe an option on composite roles (show all, show composite, show
> > children)?
> >
> 
> 
> That sounds good.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu Mar  6 11:13:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 6 Mar 2014 11:13:47 -0500 (EST)
Subject: [keycloak-dev] please update JIRA for alpha 3
In-Reply-To: <531897C7.4000500@redhat.com>
References: <531897C7.4000500@redhat.com>
Message-ID: <2035865144.22099222.1394122427264.JavaMail.zimbra@redhat.com>

Sure, can you create 1.0-alpha-4 in jira please?

With regards to https://issues.jboss.org/browse/KEYCLOAK-336, I think we need to fix it asap. Quick fix is just to drop pagination from all tables, then add it back in properly when we have time. If you're ok with that I can sort it out tomorrow.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 6 March, 2014 3:44:07 PM
> Subject: [keycloak-dev] please update JIRA for alpha 3
> 
> Please close alpha 3 issues you have completed.  Defer others that you
> will not get done by next Tuesday.
> 
> Thanks,
> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Mar  6 11:00:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 11:00:24 -0500
Subject: [keycloak-dev] discontinuing scope param
In-Reply-To: <53189B0B.9050306@redhat.com>
References: <5317AD8E.7090001@redhat.com>
	<53188A88.7010900@redhat.com>	<1331416654.22013442.1394118095487.JavaMail.zimbra@redhat.com>	<531890C8.9080401@redhat.com>	<498042838.22028033.1394119467263.JavaMail.zimbra@redhat.com>	<53189704.2000409@redhat.com>	<1362847938.22054379.1394120665558.JavaMail.zimbra@redhat.com>	<5318991C.7060401@redhat.com>	<99650028.22064551.1394121375742.JavaMail.zimbra@redhat.com>
	<53189B0B.9050306@redhat.com>
Message-ID: <53189B98.5060700@redhat.com>



On 3/6/2014 10:58 AM, Bill Burke wrote:
>> My questions still stands, would it not just be a mechanism for a client to obtain permissions without the users knowledge?
>>
>
> Yes.  Some people might like to ignore privacy policies ;)
>

Seriously though, there may be fine grained roles that are 
implementation specific that the user wouldn't even understand what they 
were.

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

From gcardoso at redhat.com  Thu Mar  6 14:09:58 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Thu, 6 Mar 2014 16:09:58 -0300
Subject: [keycloak-dev] Navigation inconsistency
Message-ID: <599A82A9-4677-45D9-9084-C8766C822E16@redhat.com>

I was exploring Keycloak console and saw some navigation inconsistency.

When the user is in the Roles page, the top navbar is shown (General, Social, Roles?):


When he clicks to add a Role, the top navbar disappear. Since he is just one level deeper, the navbar should NOT be hidden.


This behaviour happens in other situations, when in ?addition? pages. Was this planned or is it an error that we want to fix?

Gabriel

--
Gabriel Cardoso
User Experience Designer @ Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140306/9ceb3aa4/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-03-06 at 3.46.41 PM.png
Type: image/png
Size: 67957 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140306/9ceb3aa4/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-03-06 at 3.46.49 PM.png
Type: image/png
Size: 56134 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140306/9ceb3aa4/attachment-0003.png 

From bburke at redhat.com  Thu Mar  6 15:09:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 06 Mar 2014 15:09:30 -0500
Subject: [keycloak-dev] Navigation inconsistency
In-Reply-To: <599A82A9-4677-45D9-9084-C8766C822E16@redhat.com>
References: <599A82A9-4677-45D9-9084-C8766C822E16@redhat.com>
Message-ID: <5318D5FA.9000605@redhat.com>

Nope, not planned.  Log a jira please?

On 3/6/2014 2:09 PM, Gabriel Cardoso wrote:
> I was exploring Keycloak console and saw some navigation inconsistency.
>
> When the user is in the Roles page, the top navbar is shown (General,
> Social, Roles?):
>
> When he clicks to add a Role, the top navbar disappear. Since he is just
> one level deeper, the navbar should NOT be hidden.
>
> This behaviour happens in other situations, when in ?addition? pages.
> Was this planned or is it an error that we want to fix?
>
> Gabriel
>
> --
> Gabriel Cardoso
> User Experience Designer @ Red Hat
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Fri Mar  7 08:26:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Mar 2014 08:26:50 -0500
Subject: [keycloak-dev] Support for installed applications added
 (including example)
In-Reply-To: <1119534784.21815064.1394108105542.JavaMail.zimbra@redhat.com>
References: <1119534784.21815064.1394108105542.JavaMail.zimbra@redhat.com>
Message-ID: <5319C91A.3000902@redhat.com>

Couuldn't a lot of the example be pulled into an adapter library and 
reused?  Also, is there any security hole you've introduced with being 
able to cut/paste the access token from the browser?  If there is a 
public client, can a hacker now get an access token?

Another thing, Android and iOS native apps can redirect to the browser 
(and vice versa), wouldn't that approach be used in mobile over this?

On 3/6/2014 7:15 AM, Stian Thorgersen wrote:
> Support for installed applications in form of two special redirect uris (urn:ietf:wg:oauth:2.0:oob and http://localhost) has been added.
>
> There's also a basic example. To try it out start the server as normal, create an app for it (mark it as public). Download the keycloak.json file. Then run:
>
> # mvn -pl examples/demo-template/customer-app-cli install exec:java -Dexec.args="<path to keycloak.json>"
>
> You can then run different commands to try it out. It has two different ways to login the user:
>
> * login-desktop: this opens a ServerSocket on a local port, opens the login url in the browser, after login the ServerSocket is used to retrieve the code
> * login-manual: this uses the 'urn:ietf:wg:oauth:2.0:oob' redirect to display the code in the browser and the user has to manually copy/paste this into the application
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Fri Mar  7 09:13:35 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 7 Mar 2014 09:13:35 -0500 (EST)
Subject: [keycloak-dev] Support for installed applications added
 (including example)
In-Reply-To: <5319C91A.3000902@redhat.com>
References: <1119534784.21815064.1394108105542.JavaMail.zimbra@redhat.com>
	<5319C91A.3000902@redhat.com>
Message-ID: <1592153205.23009668.1394201615740.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 7 March, 2014 1:26:50 PM
> Subject: Re: [keycloak-dev] Support for installed applications added (including example)
> 
> Couuldn't a lot of the example be pulled into an adapter library and
> reused?  

Yes, that would be good. I mainly wanted to tick the box that we support installed applications. With these redirect uris we can claim we support CLI, desktop apps, etc..

> Also, is there any security hole you've introduced with being
> able to cut/paste the access token from the browser?  If there is a
> public client, can a hacker now get an access token?

Don't think so. It's just the code that's available not the token, and that's available from the query param in either case. It just displays it in the title and page instead.

BTW this is exactly what Google provides (https://developers.google.com/accounts/docs/OAuth2InstalledApp). 

> 
> Another thing, Android and iOS native apps can redirect to the browser
> (and vice versa), wouldn't that approach be used in mobile over this?

For iOS, and probably Android as well, a custom URL scheme is used to redirect to the application itself (something like myapp://oauth2?code=<...>).

I'm working on Cordova ATM and it's using http://localhost, but it's a bit of cheat as it doesn't start a web server instead of just gets the code and closes the browser before the page not found is displayed to the user.

> 
> On 3/6/2014 7:15 AM, Stian Thorgersen wrote:
> > Support for installed applications in form of two special redirect uris
> > (urn:ietf:wg:oauth:2.0:oob and http://localhost) has been added.
> >
> > There's also a basic example. To try it out start the server as normal,
> > create an app for it (mark it as public). Download the keycloak.json file.
> > Then run:
> >
> > # mvn -pl examples/demo-template/customer-app-cli install exec:java
> > -Dexec.args="<path to keycloak.json>"
> >
> > You can then run different commands to try it out. It has two different
> > ways to login the user:
> >
> > * login-desktop: this opens a ServerSocket on a local port, opens the login
> > url in the browser, after login the ServerSocket is used to retrieve the
> > code
> > * login-manual: this uses the 'urn:ietf:wg:oauth:2.0:oob' redirect to
> > display the code in the browser and the user has to manually copy/paste
> > this into the application
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Mar  7 10:32:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Mar 2014 10:32:49 -0500
Subject: [keycloak-dev] Support for installed applications added
 (including example)
In-Reply-To: <1592153205.23009668.1394201615740.JavaMail.zimbra@redhat.com>
References: <1119534784.21815064.1394108105542.JavaMail.zimbra@redhat.com>
	<5319C91A.3000902@redhat.com>
	<1592153205.23009668.1394201615740.JavaMail.zimbra@redhat.com>
Message-ID: <5319E6A1.6030806@redhat.com>



On 3/7/2014 9:13 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 7 March, 2014 1:26:50 PM
>> Subject: Re: [keycloak-dev] Support for installed applications added (including example)
>>
>> Couuldn't a lot of the example be pulled into an adapter library and
>> reused?
>
> Yes, that would be good. I mainly wanted to tick the box that we support installed applications. With these redirect uris we can claim we support CLI, desktop apps, etc..
>
>> Also, is there any security hole you've introduced with being
>> able to cut/paste the access token from the browser?  If there is a
>> public client, can a hacker now get an access token?
>
> Don't think so. It's just the code that's available not the token, and that's available from the query param in either case. It just displays it in the title and page instead.
>

Still sounds like a security hole for public clients.  For public 
clients we can "validate" that the access *code* is going to a valid 
client because of HTTPS.  If this "Cordova" support is on by default, 
then the hacker can just send a redirect_uri of 
"urn:ietf:wg:oauth:2.0:oob" or "http://localhost" and obtain the access 
code.  Is "CORDOVA" support on by default currently?


> BTW this is exactly what Google provides (https://developers.google.com/accounts/docs/OAuth2InstalledApp).
>

Google clients require a secret.



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

From stian at redhat.com  Fri Mar  7 10:51:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 7 Mar 2014 10:51:56 -0500 (EST)
Subject: [keycloak-dev] Support for installed applications added
 (including example)
In-Reply-To: <5319E6A1.6030806@redhat.com>
References: <1119534784.21815064.1394108105542.JavaMail.zimbra@redhat.com>
	<5319C91A.3000902@redhat.com>
	<1592153205.23009668.1394201615740.JavaMail.zimbra@redhat.com>
	<5319E6A1.6030806@redhat.com>
Message-ID: <792398935.23072254.1394207516692.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 7 March, 2014 3:32:49 PM
> Subject: Re: [keycloak-dev] Support for installed applications added (including example)
> 
> 
> 
> On 3/7/2014 9:13 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 7 March, 2014 1:26:50 PM
> >> Subject: Re: [keycloak-dev] Support for installed applications added
> >> (including example)
> >>
> >> Couuldn't a lot of the example be pulled into an adapter library and
> >> reused?
> >
> > Yes, that would be good. I mainly wanted to tick the box that we support
> > installed applications. With these redirect uris we can claim we support
> > CLI, desktop apps, etc..
> >
> >> Also, is there any security hole you've introduced with being
> >> able to cut/paste the access token from the browser?  If there is a
> >> public client, can a hacker now get an access token?
> >
> > Don't think so. It's just the code that's available not the token, and
> > that's available from the query param in either case. It just displays it
> > in the title and page instead.
> >
> 
> Still sounds like a security hole for public clients.  For public
> clients we can "validate" that the access *code* is going to a valid
> client because of HTTPS.  If this "Cordova" support is on by default,
> then the hacker can just send a redirect_uri of
> "urn:ietf:wg:oauth:2.0:oob" or "http://localhost" and obtain the access
> code.  Is "CORDOVA" support on by default currently?

No they are just regular redirect uris. As long as another redirect uri has been specified for the app they're not valid.

urn:ietf:wg:oauth:2.0:oob is not sent to any clients as its just displayed by the browser itself.

http://localhost the only difference from what we had before and what we have now is that if you specify http://localhost as a valid redirect uri, http://localhost:83249 and http://localhost:34922 will also work.

I don't understand how a hacker would use those redirect uris to obtain a code. localhost should always point to the local machine, so the code will never leave the machine. Same with urn:ietf:wg:oauth:2.0:oob in that case the only difference is that the code is displayed in the title of the page instead of the code query param. If a hacker is able to intercept the URL of a page in the browser he will be able to obtain the code no matter what the redirect-uri is. 

> 
> 
> > BTW this is exactly what Google provides
> > (https://developers.google.com/accounts/docs/OAuth2InstalledApp).
> >
> 
> Google clients require a secret.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri Mar  7 12:18:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Mar 2014 12:18:23 -0500
Subject: [keycloak-dev] Support for installed applications added
 (including example)
In-Reply-To: <792398935.23072254.1394207516692.JavaMail.zimbra@redhat.com>
References: <1119534784.21815064.1394108105542.JavaMail.zimbra@redhat.com>
	<5319C91A.3000902@redhat.com>
	<1592153205.23009668.1394201615740.JavaMail.zimbra@redhat.com>
	<5319E6A1.6030806@redhat.com>
	<792398935.23072254.1394207516692.JavaMail.zimbra@redhat.com>
Message-ID: <5319FF5F.1030305@redhat.com>



On 3/7/2014 10:51 AM, Stian Thorgersen wrote:
>
> I don't understand how a hacker would use those redirect uris to obtain a code. localhost should always point to the local machine, so the code will never leave the machine. Same with urn:ietf:wg:oauth:2.0:oob in that case the only difference is that the code is displayed in the title of the page instead of the code query param. If a hacker is able to intercept the URL of a page in the browser he will be able to obtain the code no matter what the redirect-uri is.
>

Easy, the hacker doesn't use a browser just a simple script.  The 
client_id of a public client could be known and it just does  GET 
/auth-server/realms/foo/tokens/auth-request?client_id=...&...

The server sends a Location response with a localhost uri which contains 
the query params which contains the code.

Google is protected from this because they don't have public clients.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Mar  7 12:51:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Mar 2014 12:51:23 -0500
Subject: [keycloak-dev] Support for installed applications added
 (including example)
In-Reply-To: <5319FF5F.1030305@redhat.com>
References: <1119534784.21815064.1394108105542.JavaMail.zimbra@redhat.com>	<5319C91A.3000902@redhat.com>	<1592153205.23009668.1394201615740.JavaMail.zimbra@redhat.com>	<5319E6A1.6030806@redhat.com>	<792398935.23072254.1394207516692.JavaMail.zimbra@redhat.com>
	<5319FF5F.1030305@redhat.com>
Message-ID: <531A071B.8070307@redhat.com>



On 3/7/2014 12:18 PM, Bill Burke wrote:
>
>
> On 3/7/2014 10:51 AM, Stian Thorgersen wrote:
>>
>> I don't understand how a hacker would use those redirect uris to obtain a code. localhost should always point to the local machine, so the code will never leave the machine. Same with urn:ietf:wg:oauth:2.0:oob in that case the only difference is that the code is displayed in the title of the page instead of the code query param. If a hacker is able to intercept the URL of a page in the browser he will be able to obtain the code no matter what the redirect-uri is.
>>
>
> Easy, the hacker doesn't use a browser just a simple script.  The
> client_id of a public client could be known and it just does  GET
> /auth-server/realms/foo/tokens/auth-request?client_id=...&...
>
> The server sends a Location response with a localhost uri which contains
> the query params which contains the code.
>

Ugh, I'm stupid, that could happen irregardless.


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

From bburke at redhat.com  Fri Mar  7 12:58:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 07 Mar 2014 12:58:23 -0500
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <531455F5.1010702@redhat.com>
References: <5313AF8E.2070809@redhat.com> <53144F6E.1050806@redhat.com>
	<997285748.19524773.1393840402391.JavaMail.zimbra@redhat.com>
	<531455F5.1010702@redhat.com>
Message-ID: <531A08BF.1050301@redhat.com>

Okay, I think I've figured out why confidential clients are better. 
Hacker could spoof the login page, obtain client credentials, in the 
background have a script that performs the login flow.  With a public 
client, the hacker would be able to get the access token as there is no 
protection.  With a confidential client, the hacker would not have the 
client credentials and would not be able to turn a code into a token.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From gcardoso at redhat.com  Fri Mar  7 17:18:29 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Fri, 7 Mar 2014 19:18:29 -0300
Subject: [keycloak-dev] Navigation inconsistency
In-Reply-To: <5318D5FA.9000605@redhat.com>
References: <599A82A9-4677-45D9-9084-C8766C822E16@redhat.com>
	<5318D5FA.9000605@redhat.com>
Message-ID: <FF4E98B2-3FCF-40AA-9B71-F63F1C80A9D7@redhat.com>

I?ve created three JIRAs related to navigation:

https://issues.jboss.org/browse/KEYCLOAK-351
https://issues.jboss.org/browse/KEYCLOAK-352
https://issues.jboss.org/browse/KEYCLOAK-353

Thanks,
Gabriel

On Mar 6, 2014, at 5:09 PM, Bill Burke <bburke at redhat.com> wrote:

> Nope, not planned.  Log a jira please?
> 
> On 3/6/2014 2:09 PM, Gabriel Cardoso wrote:
>> I was exploring Keycloak console and saw some navigation inconsistency.
>> 
>> When the user is in the Roles page, the top navbar is shown (General,
>> Social, Roles?):
>> 
>> When he clicks to add a Role, the top navbar disappear. Since he is just
>> one level deeper, the navbar should NOT be hidden.
>> 
>> This behaviour happens in other situations, when in ?addition? pages.
>> Was this planned or is it an error that we want to fix?
>> 
>> Gabriel
>> 
>> --
>> Gabriel Cardoso
>> User Experience Designer @ Red Hat
>> 
>> 
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

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

From stian at redhat.com  Mon Mar 10 05:57:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 10 Mar 2014 05:57:10 -0400 (EDT)
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <531A08BF.1050301@redhat.com>
References: <5313AF8E.2070809@redhat.com> <53144F6E.1050806@redhat.com>
	<997285748.19524773.1393840402391.JavaMail.zimbra@redhat.com>
	<531455F5.1010702@redhat.com> <531A08BF.1050301@redhat.com>
Message-ID: <196571514.23923428.1394445430953.JavaMail.zimbra@redhat.com>

That's at least one ;)

Confidential clients are always going to be more secure, but public clients are a requirement so whatever we can do to make them more secure would be great. At some point confidential clients needs to be exposed to a browser though, and that means they will need some way of securing the public client. Even a http-only cookie is still vulnerable. For example if there's an exploit in the browser, or the hacker gains read access to the file-system, it would be relatively easy to extract the refresh token from the cookie.

End of the day there's a few things that are outside of our control:

* Exploits in browsers
* Hackers that gain access to file-system
* Users that don't check the URL (and https certificate)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 7 March, 2014 5:58:23 PM
> Subject: Re: [keycloak-dev] why authenticate clients?
> 
> Okay, I think I've figured out why confidential clients are better.
> Hacker could spoof the login page, obtain client credentials, in the
> background have a script that performs the login flow.  With a public
> client, the hacker would be able to get the access token as there is no
> protection.  With a confidential client, the hacker would not have the
> client credentials and would not be able to turn a code into a token.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Mon Mar 10 06:02:27 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 10 Mar 2014 11:02:27 +0100
Subject: [keycloak-dev] Linking social accounts
Message-ID: <531D8DB3.2070001@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/275 for 
linking/unlinking social accounts into already existing Keycloak user 
account.

I've created another JIRA https://issues.jboss.org/browse/KEYCLOAK-354, 
which will allow that administrator will be able to see, which social 
networks are connected for user 'john'. We discussed with Stian that 
read-only possibility for admin is probably sufficient (ie. admin can 
just review that john is linked to Facebook and Google, but he doesn't 
have possibility to remove this linking or add new linking of this user 
to other social networks).

There is also this bug https://issues.jboss.org/browse/KEYCLOAK-334, 
which means that users registered through social can't change their 
passwords because changing password requires filling already existing 
password and user 'john' doesn't have existing password when he 
registered himself through Facebook... It seems that for user without 
password, there should be possibility to skip the need to fill existing 
password. Maybe there should be new model method like:

boolean  RealmModel hasPassword(UserModel user);

or even more flexible:

boolean  RealmModel hasCredential(UserModel user,String  credentialType);

Not sure if this is sufficient though, because users registered through social won't need to fill existing passwords, which could mean that someone can hijack their session as Stian pointed.

So I was also thinking if we can require that users will need to fill 
their password if they are registered through social. Maybe some 
administrators don't want this, but in fact many sites on Internet 
requires this for Social registration and in fact that's what I did in 
GateIn portal as well.

So I wonder if we shouldn't remove the realm boolean attribute 
"updateProfileOnInitialSocialLogin" and add new attribute like 
"socialRegistrationRequiredActions", which will contain array of 
required actions after social registration. So for example:
- If administrator wants users to be registered automatically through 
social without need to confirm anything, he can use empty array (same 
like currently updateProfileOnInitialSocialLogin=false)
- If administrator wants users to confirm their attributes (firstName, 
lastname, email...), he will just add action UPDATE_PROFILE (same like 
currently updateProfileOnInitialSocialLogin=true)
- If administrator wants users to confirm attributes and also fill 
password, he will add both UPDATE_PROFILE and UPDATE_PASSWORD into this 
array

wdyt?
Marek

From bburke at redhat.com  Mon Mar 10 09:01:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 10 Mar 2014 09:01:41 -0400
Subject: [keycloak-dev] Linking social accounts
In-Reply-To: <531D8DB3.2070001@redhat.com>
References: <531D8DB3.2070001@redhat.com>
Message-ID: <531DB7B5.1080308@redhat.com>


On 3/10/2014 6:02 AM, Marek Posolda wrote:
> I've sent PR https://github.com/keycloak/keycloak/pull/275 for
> linking/unlinking social accounts into already existing Keycloak user
> account.
>
> I've created another JIRA https://issues.jboss.org/browse/KEYCLOAK-354,
> which will allow that administrator will be able to see, which social
> networks are connected for user 'john'. We discussed with Stian that
> read-only possibility for admin is probably sufficient (ie. admin can
> just review that john is linked to Facebook and Google, but he doesn't
> have possibility to remove this linking or add new linking of this user
> to other social networks).
>
> There is also this bug https://issues.jboss.org/browse/KEYCLOAK-334,
> which means that users registered through social can't change their
> passwords because changing password requires filling already existing
> password and user 'john' doesn't have existing password when he
> registered himself through Facebook... It seems that for user without
> password, there should be possibility to skip the need to fill existing
> password. Maybe there should be new model method like:
>

I think I submitted a similar bug to this in regards to "forgot password".

I also want you to think about linking Social Accounts with existing 
Keycloak Accounts.  I believe sso.jboss.org will want to do this as I 
think people will want to use their Github user accounts to log into 
jboss.org JIRA without having to redo permissions.


> boolean  RealmModel hasPassword(UserModel user);
>
> or even more flexible:
>
> boolean  RealmModel hasCredential(UserModel user,String  credentialType);
>
> Not sure if this is sufficient though, because users registered through social won't need to fill existing passwords, which could mean that someone can hijack their session as Stian pointed.
>
> So I was also thinking if we can require that users will need to fill
> their password if they are registered through social. Maybe some
> administrators don't want this, but in fact many sites on Internet
> requires this for Social registration and in fact that's what I did in
> GateIn portal as well.
>

Why would a password be required for a social login?  The whole point of 
a social login is to delegate authentication.  I can see you maybe 
wanting to add 2-factor auth and other security constraints to a social 
login, but a password?  no.


> So I wonder if we shouldn't remove the realm boolean attribute
> "updateProfileOnInitialSocialLogin" and add new attribute like
> "socialRegistrationRequiredActions", which will contain array of
> required actions after social registration. So for example:
> - If administrator wants users to be registered automatically through
> social without need to confirm anything, he can use empty array (same
> like currently updateProfileOnInitialSocialLogin=false)
> - If administrator wants users to confirm their attributes (firstName,
> lastname, email...), he will just add action UPDATE_PROFILE (same like
> currently updateProfileOnInitialSocialLogin=true)
> - If administrator wants users to confirm attributes and also fill
> password, he will add both UPDATE_PROFILE and UPDATE_PASSWORD into this
> array


I'd like to see an option for "Do you have an existing account?  If so, 
please log in to link this account to your social account."

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

From bburke at redhat.com  Mon Mar 10 09:03:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 10 Mar 2014 09:03:57 -0400
Subject: [keycloak-dev] Need help this week
Message-ID: <531DB83D.1040304@redhat.com>

I'd like to get all work in by EOD tomorrow.  Would be really cool if 
everybody could run through things as much as possible and reread docs 
and stuff to make sure we're all good to release.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon Mar 10 10:05:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 10 Mar 2014 10:05:19 -0400 (EDT)
Subject: [keycloak-dev] Need help this week
In-Reply-To: <531DB83D.1040304@redhat.com>
References: <531DB83D.1040304@redhat.com>
Message-ID: <1413155328.24097931.1394460319780.JavaMail.zimbra@redhat.com>

All work is in from me, Marek, and the other portal guys.

I'll try to run through things, but I've got a sick child at the moment so the next couple days will be a bit on/off.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 10 March, 2014 1:03:57 PM
> Subject: [keycloak-dev] Need help this week
> 
> I'd like to get all work in by EOD tomorrow.  Would be really cool if
> everybody could run through things as much as possible and reread docs
> and stuff to make sure we're all good to release.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Mar 10 10:13:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 10 Mar 2014 10:13:37 -0400 (EDT)
Subject: [keycloak-dev] Linking social accounts
In-Reply-To: <531DB7B5.1080308@redhat.com>
References: <531D8DB3.2070001@redhat.com> <531DB7B5.1080308@redhat.com>
Message-ID: <1016496415.24104221.1394460817333.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 10 March, 2014 1:01:41 PM
> Subject: Re: [keycloak-dev] Linking social accounts
> 
> 
> On 3/10/2014 6:02 AM, Marek Posolda wrote:
> > I've sent PR https://github.com/keycloak/keycloak/pull/275 for
> > linking/unlinking social accounts into already existing Keycloak user
> > account.
> >
> > I've created another JIRA https://issues.jboss.org/browse/KEYCLOAK-354,
> > which will allow that administrator will be able to see, which social
> > networks are connected for user 'john'. We discussed with Stian that
> > read-only possibility for admin is probably sufficient (ie. admin can
> > just review that john is linked to Facebook and Google, but he doesn't
> > have possibility to remove this linking or add new linking of this user
> > to other social networks).
> >
> > There is also this bug https://issues.jboss.org/browse/KEYCLOAK-334,
> > which means that users registered through social can't change their
> > passwords because changing password requires filling already existing
> > password and user 'john' doesn't have existing password when he
> > registered himself through Facebook... It seems that for user without
> > password, there should be possibility to skip the need to fill existing
> > password. Maybe there should be new model method like:
> >
> 
> I think I submitted a similar bug to this in regards to "forgot password".

In the account management pages you need to provide the existing password. The login pages will allow you to reset the password through a link in an email without the password.

The account management pages asks for this password to prevent hijacking an account if someone forgets to logout from a shared machine.

> 
> I also want you to think about linking Social Accounts with existing
> Keycloak Accounts.  I believe sso.jboss.org will want to do this as I
> think people will want to use their Github user accounts to log into
> jboss.org JIRA without having to redo permissions.
> 
> 
> > boolean  RealmModel hasPassword(UserModel user);
> >
> > or even more flexible:
> >
> > boolean  RealmModel hasCredential(UserModel user,String  credentialType);
> >
> > Not sure if this is sufficient though, because users registered through
> > social won't need to fill existing passwords, which could mean that
> > someone can hijack their session as Stian pointed.
> >
> > So I was also thinking if we can require that users will need to fill
> > their password if they are registered through social. Maybe some
> > administrators don't want this, but in fact many sites on Internet
> > requires this for Social registration and in fact that's what I did in
> > GateIn portal as well.
> >
> 
> Why would a password be required for a social login?  The whole point of
> a social login is to delegate authentication.  I can see you maybe
> wanting to add 2-factor auth and other security constraints to a social
> login, but a password?  no.

Someone may have initially started using social login, but later wants to change to a regular login. To do so they would have to set a password. Also, setting a password would allow someone a backup way of accessing their account should the social network be done, they've lost their account there, or for whatever other reason they can't use the social login any more.

The best user experience would come from having a set password option in account management without requiring the 'current' password as it doesn't exist. I think that's ok, but I'm a little bit worried about that allowing someone to potentially hijack an account (see above).

> 
> 
> > So I wonder if we shouldn't remove the realm boolean attribute
> > "updateProfileOnInitialSocialLogin" and add new attribute like
> > "socialRegistrationRequiredActions", which will contain array of
> > required actions after social registration. So for example:
> > - If administrator wants users to be registered automatically through
> > social without need to confirm anything, he can use empty array (same
> > like currently updateProfileOnInitialSocialLogin=false)
> > - If administrator wants users to confirm their attributes (firstName,
> > lastname, email...), he will just add action UPDATE_PROFILE (same like
> > currently updateProfileOnInitialSocialLogin=true)
> > - If administrator wants users to confirm attributes and also fill
> > password, he will add both UPDATE_PROFILE and UPDATE_PASSWORD into this
> > array

I think that's a good idea. This would also be nice to have for standard registrations as well. At the moment we have an on/off for validate password, but it would be better to have two fields:

- Actions on first login
- Actions on first social login

These would be multi-select fields, same as we have for required fields on a users account.

> 
> 
> I'd like to see an option for "Do you have an existing account?  If so,
> please log in to link this account to your social account."

That would be nice, and we wanted to add some integration with the login forms later. This time around it's been focused on the account management. So you can add a social link to an existing account (doesn't matter if that existing account uses standard password login, or social login). You can also add as many as you want, so you can login to the same account with username/password or any of the social providers we have.


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

From bburke at redhat.com  Mon Mar 10 10:33:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 10 Mar 2014 10:33:56 -0400
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <196571514.23923428.1394445430953.JavaMail.zimbra@redhat.com>
References: <5313AF8E.2070809@redhat.com> <53144F6E.1050806@redhat.com>
	<997285748.19524773.1393840402391.JavaMail.zimbra@redhat.com>
	<531455F5.1010702@redhat.com> <531A08BF.1050301@redhat.com>
	<196571514.23923428.1394445430953.JavaMail.zimbra@redhat.com>
Message-ID: <531DCD54.8010706@redhat.com>



On 3/10/2014 5:57 AM, Stian Thorgersen wrote:
> That's at least one ;)
>
> Confidential clients are always going to be more secure, but public clients are a requirement so whatever we can do to make them more secure would be great. At some point confidential clients needs to be exposed to a browser though, and that means they will need some way of securing the public client. Even a http-only cookie is still vulnerable. For example if there's an exploit in the browser, or the hacker gains read access to the file-system, it would be relatively easy to extract the refresh token from the cookie.
>

Confidential clients don't need to expose themselves to a browser.  Only 
the access token needs to be exposed.  Confidential clients should 
always hold their credentials close and never share them.

That being said, we need to change our pure javascript adapter to be a 
public client.  Right now any attacker can get access to the client's 
credentials by doing a simple GET request, so we should make the 
developer aware that our pure Javascript adapter is not confidential by 
requiring them to click the "public" option when setting up the application.

I'd also like to have a server-side adapter to support confidential 
clients for a pure HTML 5/Javascript application.  For example, this 
server side adapter would need only one REST endpoint that would only 
perform authenticated access token requests.


> * Users that don't check the URL (and https certificate)
>

Even this is mitigated and can be mitigated even more.  Currently 
everything is digitally signed.  Keycloak adapters already verify signed 
access tokens.  They cold do the same for access codes.  Access tokens 
are also allowed in Open ID Connect to be encrypted using the client's 
secret.


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

From stian at redhat.com  Mon Mar 10 10:44:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 10 Mar 2014 10:44:18 -0400 (EDT)
Subject: [keycloak-dev] why authenticate clients?
In-Reply-To: <531DCD54.8010706@redhat.com>
References: <5313AF8E.2070809@redhat.com> <53144F6E.1050806@redhat.com>
	<997285748.19524773.1393840402391.JavaMail.zimbra@redhat.com>
	<531455F5.1010702@redhat.com> <531A08BF.1050301@redhat.com>
	<196571514.23923428.1394445430953.JavaMail.zimbra@redhat.com>
	<531DCD54.8010706@redhat.com>
Message-ID: <2010372663.24134980.1394462658314.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, 10 March, 2014 2:33:56 PM
> Subject: Re: [keycloak-dev] why authenticate clients?
> 
> 
> 
> On 3/10/2014 5:57 AM, Stian Thorgersen wrote:
> > That's at least one ;)
> >
> > Confidential clients are always going to be more secure, but public clients
> > are a requirement so whatever we can do to make them more secure would be
> > great. At some point confidential clients needs to be exposed to a browser
> > though, and that means they will need some way of securing the public
> > client. Even a http-only cookie is still vulnerable. For example if
> > there's an exploit in the browser, or the hacker gains read access to the
> > file-system, it would be relatively easy to extract the refresh token from
> > the cookie.
> >
> 
> Confidential clients don't need to expose themselves to a browser.  Only
> the access token needs to be exposed.  Confidential clients should
> always hold their credentials close and never share them.

That's what I meant. They have to expose the token to the client. Or use some completely different mechanism to authenticate the client.

> 
> That being said, we need to change our pure javascript adapter to be a
> public client.  Right now any attacker can get access to the client's
> credentials by doing a simple GET request, so we should make the
> developer aware that our pure Javascript adapter is not confidential by
> requiring them to click the "public" option when setting up the application.

Already done, the client_secret is now optional. Not sure if it even needs to be optional or if we can completely remove it. 

I need to write some documentation for the JS lib. 

> 
> I'd also like to have a server-side adapter to support confidential
> clients for a pure HTML 5/Javascript application.  For example, this
> server side adapter would need only one REST endpoint that would only
> perform authenticated access token requests.

Can you elaborate?

> 
> 
> > * Users that don't check the URL (and https certificate)
> >
> 
> Even this is mitigated and can be mitigated even more.  Currently
> everything is digitally signed.  Keycloak adapters already verify signed
> access tokens.  They cold do the same for access codes.  Access tokens
> are also allowed in Open ID Connect to be encrypted using the client's
> secret.

Maybe it can be to some extent, but if someone can direct the user to a fake login they can obtain the users username/password and with that they can do whatever the user can do. For example: 

* Get a token directly for a public client
* Get a token indirectly from a confidential client - just auth with the server, and obtain a token from the cookie instead

Once a users username/password has been compromised there's nothing you can do to stop an attacker gaining full access to the users account. Except disabling the account that is.

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

From mposolda at redhat.com  Mon Mar 10 10:49:35 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 10 Mar 2014 15:49:35 +0100
Subject: [keycloak-dev] Need help this week
In-Reply-To: <1413155328.24097931.1394460319780.JavaMail.zimbra@redhat.com>
References: <531DB83D.1040304@redhat.com>
	<1413155328.24097931.1394460319780.JavaMail.zimbra@redhat.com>
Message-ID: <531DD0FF.6080603@redhat.com>

I am going to fix and re-run CI with all databases. Besides that, I 
don't have anything more planned for Alpha3.

Marek

On 10.3.2014 15:05, Stian Thorgersen wrote:
> All work is in from me, Marek, and the other portal guys.
>
> I'll try to run through things, but I've got a sick child at the moment so the next couple days will be a bit on/off.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 10 March, 2014 1:03:57 PM
>> Subject: [keycloak-dev] Need help this week
>>
>> I'd like to get all work in by EOD tomorrow.  Would be really cool if
>> everybody could run through things as much as possible and reread docs
>> and stuff to make sure we're all good to release.
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Mon Mar 10 11:33:59 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 10 Mar 2014 16:33:59 +0100
Subject: [keycloak-dev] Linking social accounts
In-Reply-To: <1016496415.24104221.1394460817333.JavaMail.zimbra@redhat.com>
References: <531D8DB3.2070001@redhat.com> <531DB7B5.1080308@redhat.com>
	<1016496415.24104221.1394460817333.JavaMail.zimbra@redhat.com>
Message-ID: <531DDB67.4060309@redhat.com>

On 10.3.2014 15:13, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 10 March, 2014 1:01:41 PM
>> Subject: Re: [keycloak-dev] Linking social accounts
>>
>>
>> On 3/10/2014 6:02 AM, Marek Posolda wrote:
>>> I've sent PR https://github.com/keycloak/keycloak/pull/275 for
>>> linking/unlinking social accounts into already existing Keycloak user
>>> account.
>>>
>>> I've created another JIRA https://issues.jboss.org/browse/KEYCLOAK-354,
>>> which will allow that administrator will be able to see, which social
>>> networks are connected for user 'john'. We discussed with Stian that
>>> read-only possibility for admin is probably sufficient (ie. admin can
>>> just review that john is linked to Facebook and Google, but he doesn't
>>> have possibility to remove this linking or add new linking of this user
>>> to other social networks).
>>>
>>> There is also this bug https://issues.jboss.org/browse/KEYCLOAK-334,
>>> which means that users registered through social can't change their
>>> passwords because changing password requires filling already existing
>>> password and user 'john' doesn't have existing password when he
>>> registered himself through Facebook... It seems that for user without
>>> password, there should be possibility to skip the need to fill existing
>>> password. Maybe there should be new model method like:
>>>
>> I think I submitted a similar bug to this in regards to "forgot password".
> In the account management pages you need to provide the existing password. The login pages will allow you to reset the password through a link in an email without the password.
>
> The account management pages asks for this password to prevent hijacking an account if someone forgets to logout from a shared machine.
>
>> I also want you to think about linking Social Accounts with existing
>> Keycloak Accounts.  I believe sso.jboss.org will want to do this as I
>> think people will want to use their Github user accounts to log into
>> jboss.org JIRA without having to redo permissions.
This is what I did in my recent PR. So currently each user have new tab 
"social" in account management where he can link/unlink social networks 
with his account. He can obviously use just social networks configured 
for particular realm. Sorry that I did not describe it in my first mail.
>>
>>
>>> boolean  RealmModel hasPassword(UserModel user);
>>>
>>> or even more flexible:
>>>
>>> boolean  RealmModel hasCredential(UserModel user,String  credentialType);
>>>
>>> Not sure if this is sufficient though, because users registered through
>>> social won't need to fill existing passwords, which could mean that
>>> someone can hijack their session as Stian pointed.RootMongoConfigRe
>>>
>>> So I was also thinking if we can require that users will need to fill
>>> their password if they are registered through social. Maybe some
>>> administrators don't want this, but in fact many sites on Internet
>>> requires this for Social registration and in fact that's what I did in
>>> GateIn portal as well.
>>>
>> Why would a password be required for a social login?  The whole point of
>> a social login is to delegate authentication.  I can see you maybe
>> wanting to add 2-factor auth and other security constraints to a social
>> login, but a password?  no.
> Someone may have initially started using social login, but later wants to change to a regular login. To do so they would have to set a password. Also, setting a password would allow someone a backup way of accessing their account should the social network be done, they've lost their account there, or for whatever other reason they can't use the social login any more.
>
> The best user experience would come from having a set password option in account management without requiring the 'current' password as it doesn't exist. I think that's ok, but I'm a little bit worried about that allowing someone to potentially hijack an account (see above).
>
>>
>>> So I wonder if we shouldn't remove the realm boolean attribute
>>> "updateProfileOnInitialSocialLogin" and add new attribute like
>>> "socialRegistrationRequiredActions", which will contain array of
>>> required actions after social registration. So for example:
>>> - If administrator wants users to be registered automatically through
>>> social without need to confirm anything, he can use empty array (same
>>> like currently updateProfileOnInitialSocialLogin=false)
>>> - If administrator wants users to confirm their attributes (firstName,
>>> lastname, email...), he will just add action UPDATE_PROFILE (same like
>>> currently updateProfileOnInitialSocialLogin=true)
>>> - If administrator wants users to confirm attributes and also fill
>>> password, he will add both UPDATE_PROFILE and UPDATE_PASSWORD into this
>>> array
> I think that's a good idea. This would also be nice to have for standard registrations as well. At the moment we have an on/off for validate password, but it would be better to have two fields:
>
> - Actions on first login
> - Actions on first social login
>
> These would be multi-select fields, same as we have for required fields on a users account.
yeah, I can create JIRA for these and assign myself the one for "social" 
login? I wonder if it's really not sufficient to provide the possibility 
of these required actions and address 
https://issues.jboss.org/browse/KEYCLOAK-334 just with this?

I can imagine that:
- some admins want users to always setup their password immediatelly 
after social login. So they can add UPDATE_PASSWORD to required actions
- Other administrators may setup SMTP password, so people can use 
"forgot password" functionality if they want to setup/reset password.
- Other administrators don't want users to use passwords at all if they 
decided to register with social networks as Bill mentioned. I can 
imagine that some administrator doesn't want to maintain user passwords 
at DB at all and he wants all users to be registered through some social 
network like Facebook
>
>>
>> I'd like to see an option for "Do you have an existing account?  If so,
>> please log in to link this account to your social account."
> That would be nice, and we wanted to add some integration with the login forms later. This time around it's been focused on the account management. So you can add a social link to an existing account (doesn't matter if that existing account uses standard password login, or social login). You can also add as many as you want, so you can login to the same account with username/password or any of the social providers we have.
Possibility to link with existing KC account after successful social 
login seems to be much more tricky than linking/unlinking accounts in 
Account management when we know that user is already successfully logged 
in Keycloak.

Example flow:
1) I want to login into Keycloak and I click to "Login with google"
2) After login in google as user "john at gmail.com" and after confirming 
permissions, I am redirected back to Keycloak. Now Keycloak asks me: Do 
you have an existing account?
3) I click to "yes"
4) Now what exactly should happen? IMO it should display login form 
again, but without "Login with google" button. The tricky thing is, that 
I am not yet logged in Keycloak, but I want to link existing Keycloak 
account with google account "john at gmail.com". So it should allow me to 
login, but obviously now without possibility to "login with google".
5) Now user can click to "Login with Facebook", but again he doesn't 
have facebook account linked yet. So now it returns to step2. In the 
end, there could be something like recursive chain of 5 social networks 
to link during one login.

Maybe to simplify this, in step 4 it shouldn't be allowed to login with 
other social network, but just with password or TOTP?

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


From stian at redhat.com  Mon Mar 10 13:22:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 10 Mar 2014 13:22:47 -0400 (EDT)
Subject: [keycloak-dev] Linking social accounts
In-Reply-To: <531DDB67.4060309@redhat.com>
References: <531D8DB3.2070001@redhat.com> <531DB7B5.1080308@redhat.com>
	<1016496415.24104221.1394460817333.JavaMail.zimbra@redhat.com>
	<531DDB67.4060309@redhat.com>
Message-ID: <1760511614.24284252.1394472167412.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 10 March, 2014 3:33:59 PM
> Subject: Re: [keycloak-dev] Linking social accounts
> 
> On 10.3.2014 15:13, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 10 March, 2014 1:01:41 PM
> >> Subject: Re: [keycloak-dev] Linking social accounts
> >>
> >>
> >> On 3/10/2014 6:02 AM, Marek Posolda wrote:
> >>> I've sent PR https://github.com/keycloak/keycloak/pull/275 for
> >>> linking/unlinking social accounts into already existing Keycloak user
> >>> account.
> >>>
> >>> I've created another JIRA https://issues.jboss.org/browse/KEYCLOAK-354,
> >>> which will allow that administrator will be able to see, which social
> >>> networks are connected for user 'john'. We discussed with Stian that
> >>> read-only possibility for admin is probably sufficient (ie. admin can
> >>> just review that john is linked to Facebook and Google, but he doesn't
> >>> have possibility to remove this linking or add new linking of this user
> >>> to other social networks).
> >>>
> >>> There is also this bug https://issues.jboss.org/browse/KEYCLOAK-334,
> >>> which means that users registered through social can't change their
> >>> passwords because changing password requires filling already existing
> >>> password and user 'john' doesn't have existing password when he
> >>> registered himself through Facebook... It seems that for user without
> >>> password, there should be possibility to skip the need to fill existing
> >>> password. Maybe there should be new model method like:
> >>>
> >> I think I submitted a similar bug to this in regards to "forgot password".
> > In the account management pages you need to provide the existing password.
> > The login pages will allow you to reset the password through a link in an
> > email without the password.
> >
> > The account management pages asks for this password to prevent hijacking an
> > account if someone forgets to logout from a shared machine.
> >
> >> I also want you to think about linking Social Accounts with existing
> >> Keycloak Accounts.  I believe sso.jboss.org will want to do this as I
> >> think people will want to use their Github user accounts to log into
> >> jboss.org JIRA without having to redo permissions.
> This is what I did in my recent PR. So currently each user have new tab
> "social" in account management where he can link/unlink social networks
> with his account. He can obviously use just social networks configured
> for particular realm. Sorry that I did not describe it in my first mail.
> >>
> >>
> >>> boolean  RealmModel hasPassword(UserModel user);
> >>>
> >>> or even more flexible:
> >>>
> >>> boolean  RealmModel hasCredential(UserModel user,String  credentialType);
> >>>
> >>> Not sure if this is sufficient though, because users registered through
> >>> social won't need to fill existing passwords, which could mean that
> >>> someone can hijack their session as Stian pointed.RootMongoConfigRe
> >>>
> >>> So I was also thinking if we can require that users will need to fill
> >>> their password if they are registered through social. Maybe some
> >>> administrators don't want this, but in fact many sites on Internet
> >>> requires this for Social registration and in fact that's what I did in
> >>> GateIn portal as well.
> >>>
> >> Why would a password be required for a social login?  The whole point of
> >> a social login is to delegate authentication.  I can see you maybe
> >> wanting to add 2-factor auth and other security constraints to a social
> >> login, but a password?  no.
> > Someone may have initially started using social login, but later wants to
> > change to a regular login. To do so they would have to set a password.
> > Also, setting a password would allow someone a backup way of accessing
> > their account should the social network be done, they've lost their
> > account there, or for whatever other reason they can't use the social
> > login any more.
> >
> > The best user experience would come from having a set password option in
> > account management without requiring the 'current' password as it doesn't
> > exist. I think that's ok, but I'm a little bit worried about that allowing
> > someone to potentially hijack an account (see above).
> >
> >>
> >>> So I wonder if we shouldn't remove the realm boolean attribute
> >>> "updateProfileOnInitialSocialLogin" and add new attribute like
> >>> "socialRegistrationRequiredActions", which will contain array of
> >>> required actions after social registration. So for example:
> >>> - If administrator wants users to be registered automatically through
> >>> social without need to confirm anything, he can use empty array (same
> >>> like currently updateProfileOnInitialSocialLogin=false)
> >>> - If administrator wants users to confirm their attributes (firstName,
> >>> lastname, email...), he will just add action UPDATE_PROFILE (same like
> >>> currently updateProfileOnInitialSocialLogin=true)
> >>> - If administrator wants users to confirm attributes and also fill
> >>> password, he will add both UPDATE_PROFILE and UPDATE_PASSWORD into this
> >>> array
> > I think that's a good idea. This would also be nice to have for standard
> > registrations as well. At the moment we have an on/off for validate
> > password, but it would be better to have two fields:
> >
> > - Actions on first login
> > - Actions on first social login
> >
> > These would be multi-select fields, same as we have for required fields on
> > a users account.
> yeah, I can create JIRA for these and assign myself the one for "social"
> login? I wonder if it's really not sufficient to provide the possibility
> of these required actions and address
> https://issues.jboss.org/browse/KEYCLOAK-334 just with this?
> 
> I can imagine that:
> - some admins want users to always setup their password immediatelly
> after social login. So they can add UPDATE_PASSWORD to required actions
> - Other administrators may setup SMTP password, so people can use
> "forgot password" functionality if they want to setup/reset password.
> - Other administrators don't want users to use passwords at all if they
> decided to register with social networks as Bill mentioned. I can
> imagine that some administrator doesn't want to maintain user passwords
> at DB at all and he wants all users to be registered through some social
> network like Facebook

There's a JIRA for social only login. This would probably be something as simple as adding an option to disable normal login, which would remove the username/password fields from login form, and also remove the set password link in account management. Pretty simple to add.

> >
> >>
> >> I'd like to see an option for "Do you have an existing account?  If so,
> >> please log in to link this account to your social account."
> > That would be nice, and we wanted to add some integration with the login
> > forms later. This time around it's been focused on the account management.
> > So you can add a social link to an existing account (doesn't matter if
> > that existing account uses standard password login, or social login). You
> > can also add as many as you want, so you can login to the same account
> > with username/password or any of the social providers we have.
> Possibility to link with existing KC account after successful social
> login seems to be much more tricky than linking/unlinking accounts in
> Account management when we know that user is already successfully logged
> in Keycloak.
> 
> Example flow:
> 1) I want to login into Keycloak and I click to "Login with google"
> 2) After login in google as user "john at gmail.com" and after confirming
> permissions, I am redirected back to Keycloak. Now Keycloak asks me: Do
> you have an existing account?
> 3) I click to "yes"
> 4) Now what exactly should happen? IMO it should display login form
> again, but without "Login with google" button. The tricky thing is, that
> I am not yet logged in Keycloak, but I want to link existing Keycloak
> account with google account "john at gmail.com". So it should allow me to
> login, but obviously now without possibility to "login with google".
> 5) Now user can click to "Login with Facebook", but again he doesn't
> have facebook account linked yet. So now it returns to step2. In the
> end, there could be something like recursive chain of 5 social networks
> to link during one login.

I think what we have now is sufficient. Anything we add will make the most common case (one social or password) less optimal.

We could add a way for users to delete their account, as well as merging accounts.

> 
> Maybe to simplify this, in step 4 it shouldn't be allowed to login with
> other social network, but just with password or TOTP?
> 
> Marek
> >
> >
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From stian at redhat.com  Tue Mar 11 06:06:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 11 Mar 2014 06:06:00 -0400 (EDT)
Subject: [keycloak-dev] Examples
In-Reply-To: <2050749417.24788155.1394531787744.JavaMail.zimbra@redhat.com>
Message-ID: <1429943560.24791218.1394532360894.JavaMail.zimbra@redhat.com>

I find the examples a bit confusing, and also not that great to help people get started building their own apps.

One idea would be to have a single configuration of the examples. Only deployable to WildFly and deployed using the subsystem. It would be great to see these deployed (and configured) to Keycloak with a single command ('mvn clean install jboss-as:deploy'?).

Then we'd add a new repo called keycloak-quickstarts. This would contain very basic quickstarts that can be used to get started. Some initial quickstarts we could add:

* Installed application
* "Local" JavaScript application
* "Remote" JavaScript application
* Server-side application (JSF?)
* Bearer only service
* Third-party application
* WildFly deployment

For the example and quickstart it would be great to have testsuites to automate testing.

From bburke at redhat.com  Tue Mar 11 08:40:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Mar 2014 08:40:11 -0400
Subject: [keycloak-dev] Examples
In-Reply-To: <1429943560.24791218.1394532360894.JavaMail.zimbra@redhat.com>
References: <1429943560.24791218.1394532360894.JavaMail.zimbra@redhat.com>
Message-ID: <531F042B.8020100@redhat.com>



On 3/11/2014 6:06 AM, Stian Thorgersen wrote:
> I find the examples a bit confusing, and also not that great to help people get started building their own apps.
>

Err. Why?  They are extremely simple.  Especially if you follow the 
screencast tutorials.  Most Wildfly developers already know how to set 
up web.xml constraints.  As a Wildfly developer I just want to see how 
Keycloak is wired in.  Anything else is a distraction.

> One idea would be to have a single configuration of the examples. Only deployable to WildFly and deployed using the subsystem. It would be great to see these deployed (and configured) to Keycloak with a single command ('mvn clean install jboss-as:deploy'?).
>

?  The preconfigured-demo is 3 steps in the appliance-dist:

1. boot keycloak/wildfly
2. load the demo realm through the admin console.
3. mvn clean install jboss-as:deploy

The preconfigured demo works OOTB on both Wildfly, EAP, and AS7.  Its 
all spelled out in the README.md file in that directory.  The examples 
*already* use the Wildfly subsystem, just not metadata from 
standalone.xml.  And that's ok because, IMO, we're not sure yet how 
developers will want to deploy keycloak.  Many will prefer 
keycloak.json, many will prefer standalone.xml.

The unconfigured-demo exists for tutorials, where the tutorial walks you 
step by step creating the realm, applications, and users in the admin 
console.  Then configuring the web applications themselves.

> Then we'd add a new repo called keycloak-quickstarts. This would contain very basic quickstarts that can be used to get started. Some initial quickstarts we could add:
>

sure, have a repo if you want to, but the examples should be shipped 
with the distro as well.  An example repo requires extra steps to get 
the user up and running with Keycloak.   It could also get out of sync 
with the Keycloak version the user wants to run with.  What do you do if 
the person doesn't know GIT?

> * Installed application
> * "Local" JavaScript application
> * "Remote" JavaScript application
> * Server-side application (JSF?)
> * Bearer only service
> * Third-party application
> * WildFly deployment
>

The demo already has most of those examples.

I agree we need more examples, I just don't see what's wrong with the 
current ones.  I've written a lot of examples/tutorials over the years: 
EJB, JPA, JAX-RS, now Keycloak.  Users prefer insanely simple examples 
that focus on the feature they are learning about.  Then, one very large 
example that brings all the pieces together.

What we're missing is the bigger examples.

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

From stian at redhat.com  Tue Mar 11 09:55:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 11 Mar 2014 09:55:17 -0400 (EDT)
Subject: [keycloak-dev] Set enabled to default to true when creating
 applications, clients and users
In-Reply-To: <1237016495.25213185.1394546115532.JavaMail.zimbra@redhat.com>
Message-ID: <1818887002.25213206.1394546117559.JavaMail.zimbra@redhat.com>

Before when creating an application or client the 'enabled' switch was set to false, but if left untouched would change to true on save. Users would be disabled when created.

To make it consistent (and to fix enabled changing on save) I've made all default to true

From adrian.mitev at gmail.com  Wed Mar 12 04:09:30 2014
From: adrian.mitev at gmail.com (Adrian Mitev)
Date: Wed, 12 Mar 2014 10:09:30 +0200
Subject: [keycloak-dev] Examples
In-Reply-To: <531F042B.8020100@redhat.com>
References: <1429943560.24791218.1394532360894.JavaMail.zimbra@redhat.com>
	<531F042B.8020100@redhat.com>
Message-ID: <CAN_QJsFwXjhiXB5sAjgniq9Q8CFezWEzeGsjLQT9FVXu8uxycg@mail.gmail.com>

Hi guys! I have a large enterprise with multiple applications with web
front-end that store different type of data. There is a single portal that
allows the users to see aggregated data from the different applications but
the user is also allowed to see the data through the user interfaces of the
separate applications. Some of the apps are with JSF ui, other use pure
html/js + jax-rs. What I need is:
* Have a SSO so that the user can log once and browse all of the
applications
* When the portal fetches data from the other applications using REST
calls, the requests should be performed with the credentials of the
currently logged user, just as the user requested the application directly,
not through the portal

You may find such example useful.


On Tue, Mar 11, 2014 at 2:40 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 3/11/2014 6:06 AM, Stian Thorgersen wrote:
> > I find the examples a bit confusing, and also not that great to help
> people get started building their own apps.
> >
>
> Err. Why?  They are extremely simple.  Especially if you follow the
> screencast tutorials.  Most Wildfly developers already know how to set
> up web.xml constraints.  As a Wildfly developer I just want to see how
> Keycloak is wired in.  Anything else is a distraction.
>
> > One idea would be to have a single configuration of the examples. Only
> deployable to WildFly and deployed using the subsystem. It would be great
> to see these deployed (and configured) to Keycloak with a single command
> ('mvn clean install jboss-as:deploy'?).
> >
>
> ?  The preconfigured-demo is 3 steps in the appliance-dist:
>
> 1. boot keycloak/wildfly
> 2. load the demo realm through the admin console.
> 3. mvn clean install jboss-as:deploy
>
> The preconfigured demo works OOTB on both Wildfly, EAP, and AS7.  Its
> all spelled out in the README.md file in that directory.  The examples
> *already* use the Wildfly subsystem, just not metadata from
> standalone.xml.  And that's ok because, IMO, we're not sure yet how
> developers will want to deploy keycloak.  Many will prefer
> keycloak.json, many will prefer standalone.xml.
>
> The unconfigured-demo exists for tutorials, where the tutorial walks you
> step by step creating the realm, applications, and users in the admin
> console.  Then configuring the web applications themselves.
>
> > Then we'd add a new repo called keycloak-quickstarts. This would contain
> very basic quickstarts that can be used to get started. Some initial
> quickstarts we could add:
> >
>
> sure, have a repo if you want to, but the examples should be shipped
> with the distro as well.  An example repo requires extra steps to get
> the user up and running with Keycloak.   It could also get out of sync
> with the Keycloak version the user wants to run with.  What do you do if
> the person doesn't know GIT?
>
> > * Installed application
> > * "Local" JavaScript application
> > * "Remote" JavaScript application
> > * Server-side application (JSF?)
> > * Bearer only service
> > * Third-party application
> > * WildFly deployment
> >
>
> The demo already has most of those examples.
>
> I agree we need more examples, I just don't see what's wrong with the
> current ones.  I've written a lot of examples/tutorials over the years:
> EJB, JPA, JAX-RS, now Keycloak.  Users prefer insanely simple examples
> that focus on the feature they are learning about.  Then, one very large
> example that brings all the pieces together.
>
> What we're missing is the bigger examples.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140312/63be753e/attachment.html 

From stian at redhat.com  Wed Mar 12 05:57:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Mar 2014 05:57:12 -0400 (EDT)
Subject: [keycloak-dev] Need help this week
In-Reply-To: <531DD0FF.6080603@redhat.com>
References: <531DB83D.1040304@redhat.com>
	<1413155328.24097931.1394460319780.JavaMail.zimbra@redhat.com>
	<531DD0FF.6080603@redhat.com>
Message-ID: <1363527543.25791108.1394618232670.JavaMail.zimbra@redhat.com>

When do you want to release?

I've got time today to review docs/examples, and fix any minor stuff I come across. I've also just done a PR for some fixes to social.

There's also a few of the CI jobs not passing which Marek is trying to fix. It would be good to have these working before releasing.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 10 March, 2014 2:49:35 PM
> Subject: Re: [keycloak-dev] Need help this week
> 
> I am going to fix and re-run CI with all databases. Besides that, I
> don't have anything more planned for Alpha3.
> 
> Marek
> 
> On 10.3.2014 15:05, Stian Thorgersen wrote:
> > All work is in from me, Marek, and the other portal guys.
> >
> > I'll try to run through things, but I've got a sick child at the moment so
> > the next couple days will be a bit on/off.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 10 March, 2014 1:03:57 PM
> >> Subject: [keycloak-dev] Need help this week
> >>
> >> I'd like to get all work in by EOD tomorrow.  Would be really cool if
> >> everybody could run through things as much as possible and reread docs
> >> and stuff to make sure we're all good to release.
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From ken at kenfinnigan.me  Wed Mar 12 08:47:19 2014
From: ken at kenfinnigan.me (Ken Finnigan)
Date: Wed, 12 Mar 2014 08:47:19 -0400
Subject: [keycloak-dev] AngularJS PatternFly components
Message-ID: <CAKeeVe4Y0C2baQ3F2aiAMJPdU62exzmX6CHa9vVcbOFp5=cfWQ@mail.gmail.com>

All,

>From the work that Viliam and Alex have done on the console for Keycloak
and now LiveOak, it's become apparent that there are a lot of common
AngularJS components, that utilize PatternFly styles, which have simply
been copied from Keycloak to LiveOak.

We've had some discussion with the UXD team and they are interested in us
commencing an AngularJS components project under the PatternFly umbrella,
so that Keycloak and LiveOak can utilize the same code without replication.
It would also benefit future projects that wish to use AngularJS and
PatternFly.

Bill, do you have any objections about the idea to extract out common
components into a separate project?

If you're ok with the idea, it would be completely up to the Keycloak
project as to when it feels is the best time to begin using these
components so as not to impact current release schedules.

Initially it would be Keycloak and LiveOak driving the project and the
development of the components, but in time it may grow to additional
projects.

Let me know your thoughts.

Thanks
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140312/3fc5cb39/attachment.html 

From bburke at redhat.com  Wed Mar 12 08:53:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 08:53:43 -0400
Subject: [keycloak-dev] AngularJS PatternFly components
In-Reply-To: <CAKeeVe4Y0C2baQ3F2aiAMJPdU62exzmX6CHa9vVcbOFp5=cfWQ@mail.gmail.com>
References: <CAKeeVe4Y0C2baQ3F2aiAMJPdU62exzmX6CHa9vVcbOFp5=cfWQ@mail.gmail.com>
Message-ID: <532058D7.10706@redhat.com>

We're of course up or that.  I'm really happy with what the UXD team is 
doing and anything to help out their efforts is great.

On 3/12/2014 8:47 AM, Ken Finnigan wrote:
> All,
>
>  From the work that Viliam and Alex have done on the console for
> Keycloak and now LiveOak, it's become apparent that there are a lot of
> common AngularJS components, that utilize PatternFly styles, which have
> simply been copied from Keycloak to LiveOak.
>
> We've had some discussion with the UXD team and they are interested in
> us commencing an AngularJS components project under the PatternFly
> umbrella, so that Keycloak and LiveOak can utilize the same code without
> replication. It would also benefit future projects that wish to use
> AngularJS and PatternFly.
>
> Bill, do you have any objections about the idea to extract out common
> components into a separate project?
>
> If you're ok with the idea, it would be completely up to the Keycloak
> project as to when it feels is the best time to begin using these
> components so as not to impact current release schedules.
>
> Initially it would be Keycloak and LiveOak driving the project and the
> development of the components, but in time it may grow to additional
> projects.
>
> Let me know your thoughts.
>
> Thanks
> Ken
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ken at kenfinnigan.me  Wed Mar 12 08:55:31 2014
From: ken at kenfinnigan.me (Ken Finnigan)
Date: Wed, 12 Mar 2014 08:55:31 -0400
Subject: [keycloak-dev] AngularJS PatternFly components
In-Reply-To: <532058D7.10706@redhat.com>
References: <CAKeeVe4Y0C2baQ3F2aiAMJPdU62exzmX6CHa9vVcbOFp5=cfWQ@mail.gmail.com>
	<532058D7.10706@redhat.com>
Message-ID: <CAKeeVe5MqaG16x94SCuB8fVW1TKYAKLETmo0B=0raiqSBn7_hg@mail.gmail.com>

Sounds great.

We'll start the ball rolling and once we've got an initial release with
some components, you can decide the best time to start integrating it into
Keycloak.



On Wed, Mar 12, 2014 at 8:53 AM, Bill Burke <bburke at redhat.com> wrote:

> We're of course up or that.  I'm really happy with what the UXD team is
> doing and anything to help out their efforts is great.
>
> On 3/12/2014 8:47 AM, Ken Finnigan wrote:
> > All,
> >
> >  From the work that Viliam and Alex have done on the console for
> > Keycloak and now LiveOak, it's become apparent that there are a lot of
> > common AngularJS components, that utilize PatternFly styles, which have
> > simply been copied from Keycloak to LiveOak.
> >
> > We've had some discussion with the UXD team and they are interested in
> > us commencing an AngularJS components project under the PatternFly
> > umbrella, so that Keycloak and LiveOak can utilize the same code without
> > replication. It would also benefit future projects that wish to use
> > AngularJS and PatternFly.
> >
> > Bill, do you have any objections about the idea to extract out common
> > components into a separate project?
> >
> > If you're ok with the idea, it would be completely up to the Keycloak
> > project as to when it feels is the best time to begin using these
> > components so as not to impact current release schedules.
> >
> > Initially it would be Keycloak and LiveOak driving the project and the
> > development of the components, but in time it may grow to additional
> > projects.
> >
> > Let me know your thoughts.
> >
> > Thanks
> > Ken
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140312/60c6d741/attachment-0001.html 

From bburke at redhat.com  Wed Mar 12 08:57:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 08:57:47 -0400
Subject: [keycloak-dev] Need help this week
In-Reply-To: <1363527543.25791108.1394618232670.JavaMail.zimbra@redhat.com>
References: <531DB83D.1040304@redhat.com>
	<1413155328.24097931.1394460319780.JavaMail.zimbra@redhat.com>
	<531DD0FF.6080603@redhat.com>
	<1363527543.25791108.1394618232670.JavaMail.zimbra@redhat.com>
Message-ID: <532059CB.7080705@redhat.com>

I'd like to release tomorrow.  What I need is a double check on all the 
demos and that they are working on AS7/EAP/Wildfly.  Test features. 
Review/improve docs.

After release, I'm going to be writing some automated integration tests 
for the undertow adapter so we don't have to do a lot of this manual 
testing.

On 3/12/2014 5:57 AM, Stian Thorgersen wrote:
> When do you want to release?
>
> I've got time today to review docs/examples, and fix any minor stuff I come across. I've also just done a PR for some fixes to social.
>
> There's also a few of the CI jobs not passing which Marek is trying to fix. It would be good to have these working before releasing.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 10 March, 2014 2:49:35 PM
>> Subject: Re: [keycloak-dev] Need help this week
>>
>> I am going to fix and re-run CI with all databases. Besides that, I
>> don't have anything more planned for Alpha3.
>>
>> Marek
>>
>> On 10.3.2014 15:05, Stian Thorgersen wrote:
>>> All work is in from me, Marek, and the other portal guys.
>>>
>>> I'll try to run through things, but I've got a sick child at the moment so
>>> the next couple days will be a bit on/off.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, 10 March, 2014 1:03:57 PM
>>>> Subject: [keycloak-dev] Need help this week
>>>>
>>>> I'd like to get all work in by EOD tomorrow.  Would be really cool if
>>>> everybody could run through things as much as possible and reread docs
>>>> and stuff to make sure we're all good to release.
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>

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

From bburke at redhat.com  Wed Mar 12 10:18:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 10:18:52 -0400
Subject: [keycloak-dev] Can we release?
Message-ID: <53206CCC.60101@redhat.com>

I have 1 bug to track down, specifically, you can't delete a realm :) 
Other than that, unless I find other bugs, I'd like to release ASAP.


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

From stian at redhat.com  Wed Mar 12 10:33:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Mar 2014 10:33:10 -0400 (EDT)
Subject: [keycloak-dev] Can we release?
In-Reply-To: <53206CCC.60101@redhat.com>
References: <53206CCC.60101@redhat.com>
Message-ID: <359470032.26005612.1394634790506.JavaMail.zimbra@redhat.com>

No blockers here. 

I'd like to review the docs and run through the examples, but unless I find any bugs that should be done in a couple hours.

Here's a few things to include in the release blog:

* Fine grained admin access control
* Support for installed applications
* Add social network links through account management
* Token subject is changed to user id
* Users can login with username or email

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 March, 2014 2:18:52 PM
> Subject: [keycloak-dev] Can we release?
> 
> I have 1 bug to track down, specifically, you can't delete a realm :)
> Other than that, unless I find other bugs, I'd like to release ASAP.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Wed Mar 12 10:33:15 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Mar 2014 15:33:15 +0100
Subject: [keycloak-dev] Can we release?
In-Reply-To: <53206CCC.60101@redhat.com>
References: <53206CCC.60101@redhat.com>
Message-ID: <5320702B.5080204@redhat.com>

CI is passing with all databases except IBM DB2 (the only one from major 
RDBMS, which is still not covered. Hope to find the time to look at it 
for next release...). So for me it's ok to release now.

Marek

  12.3.2014 15:18, Bill Burke wrote:
> I have 1 bug to track down, specifically, you can't delete a realm :)
> Other than that, unless I find other bugs, I'd like to release ASAP.
>
>


From bburke at redhat.com  Wed Mar 12 10:42:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 10:42:28 -0400
Subject: [keycloak-dev] Can we release?
In-Reply-To: <359470032.26005612.1394634790506.JavaMail.zimbra@redhat.com>
References: <53206CCC.60101@redhat.com>
	<359470032.26005612.1394634790506.JavaMail.zimbra@redhat.com>
Message-ID: <53207254.6030603@redhat.com>

If you can, update docbook/.../MigratingFromOlderVersions.xml with 
backward incompatibilities and/or new config requirements from your commits.

On 3/12/2014 10:33 AM, Stian Thorgersen wrote:
> No blockers here.
>
> I'd like to review the docs and run through the examples, but unless I find any bugs that should be done in a couple hours.
>
> Here's a few things to include in the release blog:
>
> * Fine grained admin access control
> * Support for installed applications
> * Add social network links through account management
> * Token subject is changed to user id
> * Users can login with username or email
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 12 March, 2014 2:18:52 PM
>> Subject: [keycloak-dev] Can we release?
>>
>> I have 1 bug to track down, specifically, you can't delete a realm :)
>> Other than that, unless I find other bugs, I'd like to release ASAP.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Wed Mar 12 12:11:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Mar 2014 12:11:18 -0400 (EDT)
Subject: [keycloak-dev] Can we release?
In-Reply-To: <53207254.6030603@redhat.com>
References: <53206CCC.60101@redhat.com>
	<359470032.26005612.1394634790506.JavaMail.zimbra@redhat.com>
	<53207254.6030603@redhat.com>
Message-ID: <5058179.26068676.1394640678244.JavaMail.zimbra@redhat.com>

I propose we add a README.md in the root of examples to describe what preconfigured and unconfigured examples are. 

Can you have a look at it and merge if you're happy with it: https://github.com/keycloak/keycloak/pull/288

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 March, 2014 2:42:28 PM
> Subject: Re: [keycloak-dev] Can we release?
> 
> If you can, update docbook/.../MigratingFromOlderVersions.xml with
> backward incompatibilities and/or new config requirements from your commits.

Added not about subject being changed to user id

> 
> On 3/12/2014 10:33 AM, Stian Thorgersen wrote:
> > No blockers here.
> >
> > I'd like to review the docs and run through the examples, but unless I find
> > any bugs that should be done in a couple hours.
> >
> > Here's a few things to include in the release blog:
> >
> > * Fine grained admin access control
> > * Support for installed applications
> > * Add social network links through account management
> > * Token subject is changed to user id
> > * Users can login with username or email
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 12 March, 2014 2:18:52 PM
> >> Subject: [keycloak-dev] Can we release?
> >>
> >> I have 1 bug to track down, specifically, you can't delete a realm :)
> >> Other than that, unless I find other bugs, I'd like to release ASAP.
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed Mar 12 12:46:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 12 Mar 2014 12:46:33 -0400 (EDT)
Subject: [keycloak-dev] Sessions in admin console
In-Reply-To: <2082736067.26085846.1394642651824.JavaMail.zimbra@redhat.com>
Message-ID: <313146788.26087253.1394642792998.JavaMail.zimbra@redhat.com>

It's really nice to see logged in users, and to be able to manage sessions through the admin console. I've spotted a few issues though:

* Logout All (realm/sessions) or Logout specific user (realm/applications/app) doesn't seem to work - only thing I could do to actually logout a user was to set the not before
* Users/sessions for users logged in to admin console or account doesn't work

From bburke at redhat.com  Wed Mar 12 14:02:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 14:02:40 -0400
Subject: [keycloak-dev] Sessions in admin console
In-Reply-To: <313146788.26087253.1394642792998.JavaMail.zimbra@redhat.com>
References: <313146788.26087253.1394642792998.JavaMail.zimbra@redhat.com>
Message-ID: <5320A140.1090201@redhat.com>



On 3/12/2014 12:46 PM, Stian Thorgersen wrote:
> It's really nice to see logged in users, and to be able to manage sessions through the admin console. I've spotted a few issues though:
>
> * Logout All (realm/sessions) or Logout specific user (realm/applications/app) doesn't seem to work - only thing I could do to actually logout a user was to set the not before
> * Users/sessions for users logged in to admin console or account doesn't work

View the wildfly console.  You *are* being logged out, but your identity 
token is still active so when you get redirected to recreate the totem, 
you get relogged in.  The logout button in admin console can't change 
the user's cookies.

Maybe instead of logout call it "Invalidate SEssion"  or "Logout Session"?

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

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

From bburke at redhat.com  Wed Mar 12 14:55:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 14:55:53 -0400
Subject: [keycloak-dev] Sessions in admin console
In-Reply-To: <5320A140.1090201@redhat.com>
References: <313146788.26087253.1394642792998.JavaMail.zimbra@redhat.com>
	<5320A140.1090201@redhat.com>
Message-ID: <5320ADB9.4060903@redhat.com>

Ya know.  They way it works is kinda silly.  A Logout should probably 
set a notBefore policy too.

On 3/12/2014 2:02 PM, Bill Burke wrote:
>
>
> On 3/12/2014 12:46 PM, Stian Thorgersen wrote:
>> It's really nice to see logged in users, and to be able to manage sessions through the admin console. I've spotted a few issues though:
>>
>> * Logout All (realm/sessions) or Logout specific user (realm/applications/app) doesn't seem to work - only thing I could do to actually logout a user was to set the not before
>> * Users/sessions for users logged in to admin console or account doesn't work
>
> View the wildfly console.  You *are* being logged out, but your identity
> token is still active so when you get redirected to recreate the totem,
> you get relogged in.  The logout button in admin console can't change
> the user's cookies.
>
> Maybe instead of logout call it "Invalidate SEssion"  or "Logout Session"?
>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From bburke at redhat.com  Wed Mar 12 16:00:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 16:00:50 -0400
Subject: [keycloak-dev] Sessions in admin console
In-Reply-To: <5320ADB9.4060903@redhat.com>
References: <313146788.26087253.1394642792998.JavaMail.zimbra@redhat.com>	<5320A140.1090201@redhat.com>
	<5320ADB9.4060903@redhat.com>
Message-ID: <5320BCF2.209@redhat.com>

Ok.

LogoutAll at the Realm level from admin console will set a 
realm.notBefore policy to now.  This will force a relogin for everybody.

LogutAll at the user level creates a notBefore policy for the individual 
user.

On 3/12/2014 2:55 PM, Bill Burke wrote:
> Ya know.  They way it works is kinda silly.  A Logout should probably
> set a notBefore policy too.
>
> On 3/12/2014 2:02 PM, Bill Burke wrote:
>>
>>
>> On 3/12/2014 12:46 PM, Stian Thorgersen wrote:
>>> It's really nice to see logged in users, and to be able to manage sessions through the admin console. I've spotted a few issues though:
>>>
>>> * Logout All (realm/sessions) or Logout specific user (realm/applications/app) doesn't seem to work - only thing I could do to actually logout a user was to set the not before
>>> * Users/sessions for users logged in to admin console or account doesn't work
>>
>> View the wildfly console.  You *are* being logged out, but your identity
>> token is still active so when you get redirected to recreate the totem,
>> you get relogged in.  The logout button in admin console can't change
>> the user's cookies.
>>
>> Maybe instead of logout call it "Invalidate SEssion"  or "Logout Session"?
>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>

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

From bburke at redhat.com  Wed Mar 12 16:45:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 16:45:10 -0400
Subject: [keycloak-dev] Releasing
Message-ID: <5320C756.5090508@redhat.com>

Starting test and release of master, 4:45pm.  Please no more commits 
until I'm done.

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

From bburke at redhat.com  Wed Mar 12 18:16:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Mar 2014 18:16:00 -0400
Subject: [keycloak-dev] Keycloak alph3 released
Message-ID: <5320DCA0.5090203@redhat.com>

http://blog.keycloak.org/2014/03/12/keycloak-alpha-3-released/

keycloak.org for docs and downloads

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

From matzew at apache.org  Thu Mar 13 05:15:48 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 13 Mar 2014 10:15:48 +0100
Subject: [keycloak-dev] Alpha-3 issues
Message-ID: <CAAg5f2RGR1k+txKAPTohC_ZMWMSrrO4r8pbg2NSR9eokqnkcjQ@mail.gmail.com>

Hello,

when deploying the deployments folder of the
*keycloak-war-dist-all-1.0-alpha-3* I noticed the following*WARN*:

10:02:18,449 WARN  [org.jboss.as.ee] (MSC service thread 1-9)
JBAS011006: Not installing optional component
org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
due to exception:
org.jboss.as.server.deployment.DeploymentUnitProcessingException:
JBAS011054: Could not find default constructor for class
org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
    at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606)
    at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81)
    at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113)
[jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[rt.jar:1.7.0_09]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[rt.jar:1.7.0_09]
    at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]

Now, login (admin:admin) and the reset flow works fine. After creating a
REALM, I am on the Tab (of the new realm), but there I notice a few "Page
not found..." messages for these links:

   - Roles
   - Default Roles
   - Credentials
   - Token
   - Keys
   - Email

When I try to create a user, I am getting an error and the following occurs
in the console of the JBoss AS 7.1.1:

10:05:53,806 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Resteasy]]
(http--127.0.0.1-8080-6) Servlet.service() for servlet Resteasy threw
exception: org.jboss.resteasy.spi.UnhandledException:
java.lang.NullPointerException
    at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.13.Final.jar:]
    at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:36)
[keycloak-services-1.0-alpha-3.jar:]
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
[jbossweb-7.0.13.Final.jar:]
    at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
[jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
    at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
[jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
[jbossweb-7.0.13.Final.jar:]
    at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
Caused by: java.lang.NullPointerException
    at org.keycloak.services.resources.admin.UsersResource.updateUserFromRep(UsersResource.java:123)
[keycloak-services-1.0-alpha-3.jar:]
    at org.keycloak.services.resources.admin.UsersResource.createUser(UsersResource.java:106)
[keycloak-services-1.0-alpha-3.jar:]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.7.0_09]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[rt.jar:1.7.0_09]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_09]
    at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09]
    at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
[resteasy-jaxrs-3.0.6.Final.jar:]
    at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
[resteasy-jaxrs-3.0.6.Final.jar:]
    ... 22 more

(Not (yet) tried w/ WildFly-8, continued to use JBoss-AS711, since that
worked fine for alpha-2)

Greetings, Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140313/70a5a8f2/attachment.html 

From bburke at redhat.com  Thu Mar 13 09:21:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Mar 2014 09:21:36 -0400
Subject: [keycloak-dev] Alpha-3 issues
In-Reply-To: <CAAg5f2RGR1k+txKAPTohC_ZMWMSrrO4r8pbg2NSR9eokqnkcjQ@mail.gmail.com>
References: <CAAg5f2RGR1k+txKAPTohC_ZMWMSrrO4r8pbg2NSR9eokqnkcjQ@mail.gmail.com>
Message-ID: <5321B0E0.7050709@redhat.com>



On 3/13/2014 5:15 AM, Matthias Wessendorf wrote:
> Hello,
>
> when deploying the |deployments| folder of the
> /keycloak-war-dist-all-1.0-alpha-3/ I noticed the following/WARN/:
>
> |10:02:18,449 WARN  [org.jboss.as.ee  <http://org.jboss.as.ee>] (MSC service thread 1-9) JBAS011006: Not installing optional component org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
>      at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606)
>      at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81)
>      at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA  <http://1.0.2.GA>]
>      at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA  <http://1.0.2.GA>]
>      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
>      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
>      at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
>

Haven't figured out the above ^.  I assume you are running on EAP/AS7?

|
>
> Now, login (admin:admin) and the reset flow works fine. After creating a
> REALM, I am on the Tab (of the new realm), but there I notice a few
> "Page not found..." messages for these links:
>

Try clearing your browser cache and trying everything again.

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

From matzew at apache.org  Thu Mar 13 10:56:20 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 13 Mar 2014 15:56:20 +0100
Subject: [keycloak-dev] Alpha-3 issues
In-Reply-To: <CAAg5f2TPXyTOXWd8rdffPN+XGKKjwS9HYjzTt1Xnhs+D9FdMJQ@mail.gmail.com>
References: <CAAg5f2RGR1k+txKAPTohC_ZMWMSrrO4r8pbg2NSR9eokqnkcjQ@mail.gmail.com>
	<5321B0E0.7050709@redhat.com>
	<CAAg5f2TPXyTOXWd8rdffPN+XGKKjwS9HYjzTt1Xnhs+D9FdMJQ@mail.gmail.com>
Message-ID: <CAAg5f2QF-mu0FO-4q=o=+JTf6TNWHcj4_OY3qWLo3Ci5Ndk=VA@mail.gmail.com>

damn! email - how does it work?

Sorry, but by accident I did not reply to the list :)

* cache clearing did help;

* Regarding the NPE Bill replied "Ok, I'll take a look and push another
release.  Probably just need a null check."


-M

On Thu, Mar 13, 2014 at 2:43 PM, Matthias Wessendorf <matzew at apache.org>wrote:

>
>
>
> On Thu, Mar 13, 2014 at 2:21 PM, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 3/13/2014 5:15 AM, Matthias Wessendorf wrote:
>> > Hello,
>> >
>> > when deploying the |deployments| folder of the
>> > /keycloak-war-dist-all-1.0-alpha-3/ I noticed the following/WARN/:
>> >
>> > |10:02:18,449 WARN  [org.jboss.as.ee  <http://org.jboss.as.ee>] (MSC
>> service thread 1-9) JBAS011006: Not installing optional component
>> org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
>> due to exception:
>> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
>> JBAS011054: Could not find default constructor for class
>> org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
>> >      at
>> org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606)
>> >      at
>> org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81)
>> >      at
>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113)
>> [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>> >      at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA  <http://1.0.2.GA>]
>> >      at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA  <http://1.0.2.GA>]
>> >      at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>> [rt.jar:1.7.0_09]
>> >      at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>> [rt.jar:1.7.0_09]
>> >      at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
>> >
>>
>> Haven't figured out the above ^.  I assume you are running on EAP/AS7?
>>
>
>
> Correct - JBoss AS 7.1.1-Final
>
>
>
>>
>> |
>> >
>> > Now, login (admin:admin) and the reset flow works fine. After creating a
>> > REALM, I am on the Tab (of the new realm), but there I notice a few
>> > "Page not found..." messages for these links:
>> >
>>
>> Try clearing your browser cache and trying everything again.
>>
>
>
> great! now I could create some roles and set default roles.
>
>
> However, the NPE on user creation is still present:
>
>
>
> Caused by: java.lang.NullPointerException
>
> at
> org.keycloak.services.resources.admin.UsersResource.updateUserFromRep(UsersResource.java:123)
> [keycloak-services-1.0-alpha-3.jar:]
>
> at
> org.keycloak.services.resources.admin.UsersResource.createUser(UsersResource.java:106)
> [keycloak-services-1.0-alpha-3.jar:]
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_09]
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_09]
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_09]
>
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09]
>
> at
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> [resteasy-jaxrs-3.0.6.Final.jar:]
>
> ... 22 more
>
>
>
>
>
>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140313/b25977dd/attachment-0001.html 

From matzew at apache.org  Thu Mar 13 11:00:50 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 13 Mar 2014 16:00:50 +0100
Subject: [keycloak-dev] Alpha-3 issues
In-Reply-To: <CAAg5f2QF-mu0FO-4q=o=+JTf6TNWHcj4_OY3qWLo3Ci5Ndk=VA@mail.gmail.com>
References: <CAAg5f2RGR1k+txKAPTohC_ZMWMSrrO4r8pbg2NSR9eokqnkcjQ@mail.gmail.com>
	<5321B0E0.7050709@redhat.com>
	<CAAg5f2TPXyTOXWd8rdffPN+XGKKjwS9HYjzTt1Xnhs+D9FdMJQ@mail.gmail.com>
	<CAAg5f2QF-mu0FO-4q=o=+JTf6TNWHcj4_OY3qWLo3Ci5Ndk=VA@mail.gmail.com>
Message-ID: <CAAg5f2TP7PvSbfezQP5pkKYQM+SdhK8pCOQf+cZZD6GvydFKKw@mail.gmail.com>

just saw

https://github.com/keycloak/keycloak/pull/294


let me build it locally and give it a quick run here


-M


On Thu, Mar 13, 2014 at 3:56 PM, Matthias Wessendorf <matzew at apache.org>wrote:

> damn! email - how does it work?
>
> Sorry, but by accident I did not reply to the list :)
>
> * cache clearing did help;
>
> * Regarding the NPE Bill replied "Ok, I'll take a look and push another
> release.  Probably just need a null check."
>
>
> -M
>
> On Thu, Mar 13, 2014 at 2:43 PM, Matthias Wessendorf <matzew at apache.org>wrote:
>
>>
>>
>>
>> On Thu, Mar 13, 2014 at 2:21 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>>>
>>>
>>> On 3/13/2014 5:15 AM, Matthias Wessendorf wrote:
>>> > Hello,
>>> >
>>> > when deploying the |deployments| folder of the
>>> > /keycloak-war-dist-all-1.0-alpha-3/ I noticed the following/WARN/:
>>> >
>>> > |10:02:18,449 WARN  [org.jboss.as.ee  <http://org.jboss.as.ee>] (MSC
>>> service thread 1-9) JBAS011006: Not installing optional component
>>> org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
>>> due to exception:
>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException:
>>> JBAS011054: Could not find default constructor for class
>>> org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
>>> >      at
>>> org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606)
>>> >      at
>>> org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81)
>>> >      at
>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113)
>>> [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>>> >      at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA  <http://1.0.2.GA>]
>>> >      at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA  <http://1.0.2.GA>]
>>> >      at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>> [rt.jar:1.7.0_09]
>>> >      at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>> [rt.jar:1.7.0_09]
>>> >      at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
>>> >
>>>
>>> Haven't figured out the above ^.  I assume you are running on EAP/AS7?
>>>
>>
>>
>> Correct - JBoss AS 7.1.1-Final
>>
>>
>>
>>>
>>> |
>>> >
>>> > Now, login (admin:admin) and the reset flow works fine. After creating
>>> a
>>> > REALM, I am on the Tab (of the new realm), but there I notice a few
>>> > "Page not found..." messages for these links:
>>> >
>>>
>>> Try clearing your browser cache and trying everything again.
>>>
>>
>>
>> great! now I could create some roles and set default roles.
>>
>>
>> However, the NPE on user creation is still present:
>>
>>
>>
>> Caused by: java.lang.NullPointerException
>>
>> at
>> org.keycloak.services.resources.admin.UsersResource.updateUserFromRep(UsersResource.java:123)
>> [keycloak-services-1.0-alpha-3.jar:]
>>
>> at
>> org.keycloak.services.resources.admin.UsersResource.createUser(UsersResource.java:106)
>> [keycloak-services-1.0-alpha-3.jar:]
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [rt.jar:1.7.0_09]
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> [rt.jar:1.7.0_09]
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.7.0_09]
>>
>> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09]
>>
>> at
>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>> [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>> ... 22 more
>>
>>
>>
>>
>>
>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140313/34caa07a/attachment.html 

From bburke at redhat.com  Thu Mar 13 11:12:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Mar 2014 11:12:24 -0400
Subject: [keycloak-dev] Alpha-3 issues
In-Reply-To: <CAAg5f2TP7PvSbfezQP5pkKYQM+SdhK8pCOQf+cZZD6GvydFKKw@mail.gmail.com>
References: <CAAg5f2RGR1k+txKAPTohC_ZMWMSrrO4r8pbg2NSR9eokqnkcjQ@mail.gmail.com>	<5321B0E0.7050709@redhat.com>	<CAAg5f2TPXyTOXWd8rdffPN+XGKKjwS9HYjzTt1Xnhs+D9FdMJQ@mail.gmail.com>	<CAAg5f2QF-mu0FO-4q=o=+JTf6TNWHcj4_OY3qWLo3Ci5Ndk=VA@mail.gmail.com>
	<CAAg5f2TP7PvSbfezQP5pkKYQM+SdhK8pCOQf+cZZD6GvydFKKw@mail.gmail.com>
Message-ID: <5321CAD8.7040906@redhat.com>

I was able to reproduce and fix it.  alpha 4 release incoming.

On 3/13/2014 11:00 AM, Matthias Wessendorf wrote:
> just saw
>
> https://github.com/keycloak/keycloak/pull/294
>
>
> let me build it locally and give it a quick run here
>
>
> -M
>
>
> On Thu, Mar 13, 2014 at 3:56 PM, Matthias Wessendorf <matzew at apache.org
> <mailto:matzew at apache.org>> wrote:
>
>     damn! email - how does it work?
>
>     Sorry, but by accident I did not reply to the list :)
>
>     * cache clearing did help;
>
>     * Regarding the NPE Bill replied "Ok, I'll take a look and push
>     another release.  Probably just need a null check."
>
>
>     -M
>
>     On Thu, Mar 13, 2014 at 2:43 PM, Matthias Wessendorf
>     <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>
>
>
>
>         On Thu, Mar 13, 2014 at 2:21 PM, Bill Burke <bburke at redhat.com
>         <mailto:bburke at redhat.com>> wrote:
>
>
>
>             On 3/13/2014 5:15 AM, Matthias Wessendorf wrote:
>              > Hello,
>              >
>              > when deploying the |deployments| folder of the
>              > /keycloak-war-dist-all-1.0-alpha-3/ I noticed the
>             following/WARN/:
>              >
>              > |10:02:18,449 WARN  [org.jboss.as.ee
>             <http://org.jboss.as.ee>  <http://org.jboss.as.ee>] (MSC
>             service thread 1-9) JBAS011006: Not installing optional
>             component
>             org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
>             due to exception:
>             org.jboss.as.server.deployment.DeploymentUnitProcessingException:
>             JBAS011054: Could not find default constructor for class
>             org.jboss.resteasy.plugins.server.servlet.Servlet3AsyncHttpRequest$Servlet3ExecutionContext$Servle3AsychronousResponse
>              >      at
>             org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606)
>              >      at
>             org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:81)
>              >      at
>             org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113)
>             [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>              >      at
>             org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>             [jboss-msc-1.0.2.GA.jar:1.0.2.GA <http://1.0.2.GA>
>               <http://1.0.2.GA>]
>              >      at
>             org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>             [jboss-msc-1.0.2.GA.jar:1.0.2.GA <http://1.0.2.GA>
>               <http://1.0.2.GA>]
>              >      at
>             java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>             [rt.jar:1.7.0_09]
>              >      at
>             java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>             [rt.jar:1.7.0_09]
>              >      at java.lang.Thread.run(Thread.java:722)
>             [rt.jar:1.7.0_09]
>              >
>
>             Haven't figured out the above ^.  I assume you are running
>             on EAP/AS7?
>
>
>
>         Correct - JBoss AS 7.1.1-Final
>
>
>             |
>              >
>              > Now, login (admin:admin) and the reset flow works fine.
>             After creating a
>              > REALM, I am on the Tab (of the new realm), but there I
>             notice a few
>              > "Page not found..." messages for these links:
>              >
>
>             Try clearing your browser cache and trying everything again.
>
>
>
>         great! now I could create some roles and set default roles.
>
>
>         However, the NPE on user creation is still present:
>
>
>
>         Caused by: java.lang.NullPointerException
>
>         at
>         org.keycloak.services.resources.admin.UsersResource.updateUserFromRep(UsersResource.java:123)
>         [keycloak-services-1.0-alpha-3.jar:]
>
>         at
>         org.keycloak.services.resources.admin.UsersResource.createUser(UsersResource.java:106)
>         [keycloak-services-1.0-alpha-3.jar:]
>
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         [rt.jar:1.7.0_09]
>
>         at
>         sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         [rt.jar:1.7.0_09]
>
>         at
>         sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         [rt.jar:1.7.0_09]
>
>         at java.lang.reflect.Method.invoke(Method.java:601)
>         [rt.jar:1.7.0_09]
>
>         at
>         org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         at
>         org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>         [resteasy-jaxrs-3.0.6.Final.jar:]
>
>         ... 22 more
>
>
>
>
>
>
>             --
>             Bill Burke
>             JBoss, a division of Red Hat
>             http://bill.burkecentral.com
>             _______________________________________________
>             keycloak-dev mailing list
>             keycloak-dev at lists.jboss.org
>             <mailto:keycloak-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>         --
>         Matthias Wessendorf
>
>         blog: http://matthiaswessendorf.wordpress.com/
>         sessions: http://www.slideshare.net/mwessendorf
>         twitter: http://twitter.com/mwessendorf
>
>
>
>
>     --
>     Matthias Wessendorf
>
>     blog: http://matthiaswessendorf.wordpress.com/
>     sessions: http://www.slideshare.net/mwessendorf
>     twitter: http://twitter.com/mwessendorf
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf

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

From matzew at apache.org  Thu Mar 13 11:16:10 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 13 Mar 2014 16:16:10 +0100
Subject: [keycloak-dev] Alpha-3 issues
In-Reply-To: <5321CAD8.7040906@redhat.com>
References: <CAAg5f2RGR1k+txKAPTohC_ZMWMSrrO4r8pbg2NSR9eokqnkcjQ@mail.gmail.com>
	<5321B0E0.7050709@redhat.com>
	<CAAg5f2TPXyTOXWd8rdffPN+XGKKjwS9HYjzTt1Xnhs+D9FdMJQ@mail.gmail.com>
	<CAAg5f2QF-mu0FO-4q=o=+JTf6TNWHcj4_OY3qWLo3Ci5Ndk=VA@mail.gmail.com>
	<CAAg5f2TP7PvSbfezQP5pkKYQM+SdhK8pCOQf+cZZD6GvydFKKw@mail.gmail.com>
	<5321CAD8.7040906@redhat.com>
Message-ID: <CAAg5f2RpwMjJ0RZJhsMKSvqPtmjAtZvEaDTaU5PwZJZtbXyt0A@mail.gmail.com>

On Thu, Mar 13, 2014 at 4:12 PM, Bill Burke <bburke at redhat.com> wrote:

> I was able to reproduce and fix it.  alpha 4 release incoming.



awesome!

local creation of user works fine!

thanks

-Matthias


>
>
> On 3/13/2014 11:00 AM, Matthias Wessendorf wrote:
>
>> just saw
>>
>> https://github.com/keycloak/keycloak/pull/294
>>
>>
>> let me build it locally and give it a quick run here
>>
>>
>> -M
>>
>>
>> On Thu, Mar 13, 2014 at 3:56 PM, Matthias Wessendorf <matzew at apache.org
>> <mailto:matzew at apache.org>> wrote:
>>
>>     damn! email - how does it work?
>>
>>     Sorry, but by accident I did not reply to the list :)
>>
>>     * cache clearing did help;
>>
>>     * Regarding the NPE Bill replied "Ok, I'll take a look and push
>>     another release.  Probably just need a null check."
>>
>>
>>     -M
>>
>>     On Thu, Mar 13, 2014 at 2:43 PM, Matthias Wessendorf
>>     <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>>
>>
>>
>>
>>         On Thu, Mar 13, 2014 at 2:21 PM, Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>             On 3/13/2014 5:15 AM, Matthias Wessendorf wrote:
>>              > Hello,
>>              >
>>              > when deploying the |deployments| folder of the
>>              > /keycloak-war-dist-all-1.0-alpha-3/ I noticed the
>>             following/WARN/:
>>              >
>>              > |10:02:18,449 WARN  [org.jboss.as.ee
>>             <http://org.jboss.as.ee>  <http://org.jboss.as.ee>] (MSC
>>
>>             service thread 1-9) JBAS011006: Not installing optional
>>             component
>>             org.jboss.resteasy.plugins.server.servlet.
>> Servlet3AsyncHttpRequest$Servlet3ExecutionContext$
>> Servle3AsychronousResponse
>>             due to exception:
>>             org.jboss.as.server.deployment.DeploymentUnitProcessingExcept
>> ion:
>>             JBAS011054: Could not find default constructor for class
>>             org.jboss.resteasy.plugins.server.servlet.
>> Servlet3AsyncHttpRequest$Servlet3ExecutionContext$
>> Servle3AsychronousResponse
>>              >      at
>>             org.jboss.as.ee.component.ComponentDescription$
>> DefaultComponentConfigurator.configure(ComponentDescription.java:606)
>>              >      at
>>             org.jboss.as.ee.component.deployers.
>> EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor
>> .java:81)
>>              >      at
>>             org.jboss.as.server.deployment.DeploymentUnitPhaseService.
>> start(DeploymentUnitPhaseService.java:113)
>>             [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>>              >      at
>>             org.jboss.msc.service.ServiceControllerImpl$
>> StartTask.startService(ServiceControllerImpl.java:1811)
>>             [jboss-msc-1.0.2.GA.jar:1.0.2.GA <http://1.0.2.GA>
>>               <http://1.0.2.GA>]
>>              >      at
>>             org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
>> ServiceControllerImpl.java:1746)
>>             [jboss-msc-1.0.2.GA.jar:1.0.2.GA <http://1.0.2.GA>
>>               <http://1.0.2.GA>]
>>              >      at
>>             java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1110)
>>             [rt.jar:1.7.0_09]
>>              >      at
>>             java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:603)
>>             [rt.jar:1.7.0_09]
>>              >      at java.lang.Thread.run(Thread.java:722)
>>             [rt.jar:1.7.0_09]
>>              >
>>
>>             Haven't figured out the above ^.  I assume you are running
>>             on EAP/AS7?
>>
>>
>>
>>         Correct - JBoss AS 7.1.1-Final
>>
>>
>>             |
>>              >
>>              > Now, login (admin:admin) and the reset flow works fine.
>>             After creating a
>>              > REALM, I am on the Tab (of the new realm), but there I
>>             notice a few
>>              > "Page not found..." messages for these links:
>>              >
>>
>>             Try clearing your browser cache and trying everything again.
>>
>>
>>
>>         great! now I could create some roles and set default roles.
>>
>>
>>         However, the NPE on user creation is still present:
>>
>>
>>
>>         Caused by: java.lang.NullPointerException
>>
>>         at
>>         org.keycloak.services.resources.admin.UsersResource.
>> updateUserFromRep(UsersResource.java:123)
>>         [keycloak-services-1.0-alpha-3.jar:]
>>
>>         at
>>         org.keycloak.services.resources.admin.UsersResource.
>> createUser(UsersResource.java:106)
>>         [keycloak-services-1.0-alpha-3.jar:]
>>
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         [rt.jar:1.7.0_09]
>>
>>         at
>>         sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:57)
>>         [rt.jar:1.7.0_09]
>>
>>         at
>>         sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>>         [rt.jar:1.7.0_09]
>>
>>         at java.lang.reflect.Method.invoke(Method.java:601)
>>         [rt.jar:1.7.0_09]
>>
>>         at
>>         org.jboss.resteasy.core.MethodInjectorImpl.invoke(
>> MethodInjectorImpl.java:137)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(
>> ResourceMethodInvoker.java:280)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceMethodInvoker.invoke(
>> ResourceMethodInvoker.java:234)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:140)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:109)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:109)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:103)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.SynchronousDispatcher.invoke(
>> SynchronousDispatcher.java:356)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         ... 22 more
>>
>>
>>
>>
>>
>>
>>             --
>>             Bill Burke
>>             JBoss, a division of Red Hat
>>             http://bill.burkecentral.com
>>             _______________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>         --
>>         Matthias Wessendorf
>>
>>         blog: http://matthiaswessendorf.wordpress.com/
>>         sessions: http://www.slideshare.net/mwessendorf
>>         twitter: http://twitter.com/mwessendorf
>>
>>
>>
>>
>>     --
>>     Matthias Wessendorf
>>
>>     blog: http://matthiaswessendorf.wordpress.com/
>>     sessions: http://www.slideshare.net/mwessendorf
>>     twitter: http://twitter.com/mwessendorf
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140313/d7350614/attachment-0001.html 

From matzew at apache.org  Thu Mar 13 11:26:34 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 13 Mar 2014 16:26:34 +0100
Subject: [keycloak-dev] Keycloak Alpha-4 (was: Re:  Alpha-3 issues)
Message-ID: <CAAg5f2QpcXEWsqaQMJ7JqG3HXeHtdCOyJ+cU+yUbE7WHK6B_Yg@mail.gmail.com>

On Thu, Mar 13, 2014 at 4:12 PM, Bill Burke <bburke at redhat.com> wrote:

> I was able to reproduce and fix it.  alpha 4 release incoming.
>
>
Besides the previous NPE on user creation:

I can confirm the alpha-4 works also fine w/ the UPS branch that aims to
integrate Keycloak!

Thanks for the quick reply!

Cheers!
Matthias




>
> On 3/13/2014 11:00 AM, Matthias Wessendorf wrote:
>
>> just saw
>>
>> https://github.com/keycloak/keycloak/pull/294
>>
>>
>> let me build it locally and give it a quick run here
>>
>>
>> -M
>>
>>
>> On Thu, Mar 13, 2014 at 3:56 PM, Matthias Wessendorf <matzew at apache.org
>> <mailto:matzew at apache.org>> wrote:
>>
>>     damn! email - how does it work?
>>
>>     Sorry, but by accident I did not reply to the list :)
>>
>>     * cache clearing did help;
>>
>>     * Regarding the NPE Bill replied "Ok, I'll take a look and push
>>     another release.  Probably just need a null check."
>>
>>
>>     -M
>>
>>     On Thu, Mar 13, 2014 at 2:43 PM, Matthias Wessendorf
>>     <matzew at apache.org <mailto:matzew at apache.org>> wrote:
>>
>>
>>
>>
>>         On Thu, Mar 13, 2014 at 2:21 PM, Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>             On 3/13/2014 5:15 AM, Matthias Wessendorf wrote:
>>              > Hello,
>>              >
>>              > when deploying the |deployments| folder of the
>>              > /keycloak-war-dist-all-1.0-alpha-3/ I noticed the
>>             following/WARN/:
>>              >
>>              > |10:02:18,449 WARN  [org.jboss.as.ee
>>             <http://org.jboss.as.ee>  <http://org.jboss.as.ee>] (MSC
>>
>>             service thread 1-9) JBAS011006: Not installing optional
>>             component
>>             org.jboss.resteasy.plugins.server.servlet.
>> Servlet3AsyncHttpRequest$Servlet3ExecutionContext$
>> Servle3AsychronousResponse
>>             due to exception:
>>             org.jboss.as.server.deployment.DeploymentUnitProcessingExcept
>> ion:
>>             JBAS011054: Could not find default constructor for class
>>             org.jboss.resteasy.plugins.server.servlet.
>> Servlet3AsyncHttpRequest$Servlet3ExecutionContext$
>> Servle3AsychronousResponse
>>              >      at
>>             org.jboss.as.ee.component.ComponentDescription$
>> DefaultComponentConfigurator.configure(ComponentDescription.java:606)
>>              >      at
>>             org.jboss.as.ee.component.deployers.
>> EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor
>> .java:81)
>>              >      at
>>             org.jboss.as.server.deployment.DeploymentUnitPhaseService.
>> start(DeploymentUnitPhaseService.java:113)
>>             [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>>              >      at
>>             org.jboss.msc.service.ServiceControllerImpl$
>> StartTask.startService(ServiceControllerImpl.java:1811)
>>             [jboss-msc-1.0.2.GA.jar:1.0.2.GA <http://1.0.2.GA>
>>               <http://1.0.2.GA>]
>>              >      at
>>             org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
>> ServiceControllerImpl.java:1746)
>>             [jboss-msc-1.0.2.GA.jar:1.0.2.GA <http://1.0.2.GA>
>>               <http://1.0.2.GA>]
>>              >      at
>>             java.util.concurrent.ThreadPoolExecutor.runWorker(
>> ThreadPoolExecutor.java:1110)
>>             [rt.jar:1.7.0_09]
>>              >      at
>>             java.util.concurrent.ThreadPoolExecutor$Worker.run(
>> ThreadPoolExecutor.java:603)
>>             [rt.jar:1.7.0_09]
>>              >      at java.lang.Thread.run(Thread.java:722)
>>             [rt.jar:1.7.0_09]
>>              >
>>
>>             Haven't figured out the above ^.  I assume you are running
>>             on EAP/AS7?
>>
>>
>>
>>         Correct - JBoss AS 7.1.1-Final
>>
>>
>>             |
>>              >
>>              > Now, login (admin:admin) and the reset flow works fine.
>>             After creating a
>>              > REALM, I am on the Tab (of the new realm), but there I
>>             notice a few
>>              > "Page not found..." messages for these links:
>>              >
>>
>>             Try clearing your browser cache and trying everything again.
>>
>>
>>
>>         great! now I could create some roles and set default roles.
>>
>>
>>         However, the NPE on user creation is still present:
>>
>>
>>
>>         Caused by: java.lang.NullPointerException
>>
>>         at
>>         org.keycloak.services.resources.admin.UsersResource.
>> updateUserFromRep(UsersResource.java:123)
>>         [keycloak-services-1.0-alpha-3.jar:]
>>
>>         at
>>         org.keycloak.services.resources.admin.UsersResource.
>> createUser(UsersResource.java:106)
>>         [keycloak-services-1.0-alpha-3.jar:]
>>
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         [rt.jar:1.7.0_09]
>>
>>         at
>>         sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:57)
>>         [rt.jar:1.7.0_09]
>>
>>         at
>>         sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>>         [rt.jar:1.7.0_09]
>>
>>         at java.lang.reflect.Method.invoke(Method.java:601)
>>         [rt.jar:1.7.0_09]
>>
>>         at
>>         org.jboss.resteasy.core.MethodInjectorImpl.invoke(
>> MethodInjectorImpl.java:137)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(
>> ResourceMethodInvoker.java:280)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceMethodInvoker.invoke(
>> ResourceMethodInvoker.java:234)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:140)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:109)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:109)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.
>> invokeOnTargetObject(ResourceLocatorInvoker.java:135)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(
>> ResourceLocatorInvoker.java:103)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         at
>>         org.jboss.resteasy.core.SynchronousDispatcher.invoke(
>> SynchronousDispatcher.java:356)
>>         [resteasy-jaxrs-3.0.6.Final.jar:]
>>
>>         ... 22 more
>>
>>
>>
>>
>>
>>
>>             --
>>             Bill Burke
>>             JBoss, a division of Red Hat
>>             http://bill.burkecentral.com
>>             _______________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>         --
>>         Matthias Wessendorf
>>
>>         blog: http://matthiaswessendorf.wordpress.com/
>>         sessions: http://www.slideshare.net/mwessendorf
>>         twitter: http://twitter.com/mwessendorf
>>
>>
>>
>>
>>     --
>>     Matthias Wessendorf
>>
>>     blog: http://matthiaswessendorf.wordpress.com/
>>     sessions: http://www.slideshare.net/mwessendorf
>>     twitter: http://twitter.com/mwessendorf
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140313/38fe443b/attachment.html 

From bburke at redhat.com  Thu Mar 13 11:43:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 13 Mar 2014 11:43:30 -0400
Subject: [keycloak-dev] next release Beta 1 May timeframe
Message-ID: <5321D222.9070508@redhat.com>

I'd like for the next release (Beta-1) to be our last major feature 
release. We'll shoot for early May as.  I personally will be disrupted 
1-2 weeks because of Red Hat Summit/DevNation

Must Have:

* Fine grain import/export of keycloak store
* LDAP/AD support
* Audit Log
* Acct Service oauth revocation
* Social login remember me
* Multi-tenant adapter abilities (for Travis)
* Any bootstrap requirements Aerogear needs
* Admin console needs to be rebrandable and support different themes. 
This is an Aerogear requirement
* Server needs to be able to run on Resteasy 2.3.6 (EAP 6.x).  A must if 
we want to get keycloak into EAP through UPS.

Would like to have:
* Jira adapter.  Have a good idea on how to implement, just need to find 
the time or a volunteer.
* Tomcat, Jetty adapters
* Access control by IP Address and user geo location.  i.e. block users 
from logging in from China, or warn them.  Google does a warning if 
somebody logged into your account from China. Its how I found out how 
somebody hacked my account a few years ago.  i have a pretty good idea 
on how to implement this, just need to find the time or a volunteer.


Anything major I'm missing?


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

From stian at redhat.com  Thu Mar 13 12:20:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 13 Mar 2014 12:20:15 -0400 (EDT)
Subject: [keycloak-dev] next release Beta 1 May timeframe
In-Reply-To: <5321D222.9070508@redhat.com>
References: <5321D222.9070508@redhat.com>
Message-ID: <1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>

Must have:

* Brute force attack protection / Max failed login attempts
* Email notifications on certain events - related to audit log and your China warning idea, but things like sending users an email when failed login attempts has occured
* Mobile adapters - I can sort out a Cordova adapter (it's just a wrapper for keycloak.js), and we just need to document (maybe create examples) on how to use AeroGear for iOS and Android native

Nice to have:

* Invalidate cookies for a specific device/browser through acct mngmt - for example if someone used remember me option on a public machine by mistake they need to be able to view devices/browsers with access, and invalidate specific machines
* Multi-factory authentication SPI, and implement add one more multi-factor auth type - to show that we're not hard-coded to Google 
* Installed application adapter - extract code from example into an adapter
* Rest endpoints for realm user management - non-admin access to users in a realm. Some applications may want to be able to lookup users. Something like 'realm/<myrealm>/users'? Same as for account we'd have a few roles for a 'user-management' application that can be granted to users

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 March, 2014 3:43:30 PM
> Subject: [keycloak-dev] next release Beta 1 May timeframe
> 
> I'd like for the next release (Beta-1) to be our last major feature
> release. We'll shoot for early May as.  I personally will be disrupted
> 1-2 weeks because of Red Hat Summit/DevNation
> 
> Must Have:
> 
> * Fine grain import/export of keycloak store
> * LDAP/AD support
> * Audit Log
> * Acct Service oauth revocation
> * Social login remember me
> * Multi-tenant adapter abilities (for Travis)
> * Any bootstrap requirements Aerogear needs
> * Admin console needs to be rebrandable and support different themes.
> This is an Aerogear requirement
> * Server needs to be able to run on Resteasy 2.3.6 (EAP 6.x).  A must if
> we want to get keycloak into EAP through UPS.
> 
> Would like to have:
> * Jira adapter.  Have a good idea on how to implement, just need to find
> the time or a volunteer.
> * Tomcat, Jetty adapters
> * Access control by IP Address and user geo location.  i.e. block users
> from logging in from China, or warn them.  Google does a warning if
> somebody logged into your account from China. Its how I found out how
> somebody hacked my account a few years ago.  i have a pretty good idea
> on how to implement this, just need to find the time or a volunteer.
> 
> 
> Anything major I'm missing?
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Fri Mar 14 05:53:01 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 14 Mar 2014 10:53:01 +0100
Subject: [keycloak-dev] next release Beta 1 May timeframe
In-Reply-To: <1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
References: <5321D222.9070508@redhat.com>
	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
Message-ID: <5322D17D.5010307@redhat.com>

I would add to "Must have" this:
- Secured storage of private keys
- Address issues with "state" on TokenManager and SocialRequestManager 
in memory. Would be useful for clustering, and to avoid memory leak 
issues like https://issues.jboss.org/browse/KEYCLOAK-323

Marek

On 13.3.2014 17:20, Stian Thorgersen wrote:
> Must have:
>
> * Brute force attack protection / Max failed login attempts
> * Email notifications on certain events - related to audit log and your China warning idea, but things like sending users an email when failed login attempts has occured
> * Mobile adapters - I can sort out a Cordova adapter (it's just a wrapper for keycloak.js), and we just need to document (maybe create examples) on how to use AeroGear for iOS and Android native
>
> Nice to have:
>
> * Invalidate cookies for a specific device/browser through acct mngmt - for example if someone used remember me option on a public machine by mistake they need to be able to view devices/browsers with access, and invalidate specific machines
> * Multi-factory authentication SPI, and implement add one more multi-factor auth type - to show that we're not hard-coded to Google
> * Installed application adapter - extract code from example into an adapter
> * Rest endpoints for realm user management - non-admin access to users in a realm. Some applications may want to be able to lookup users. Something like 'realm/<myrealm>/users'? Same as for account we'd have a few roles for a 'user-management' application that can be granted to users
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 13 March, 2014 3:43:30 PM
>> Subject: [keycloak-dev] next release Beta 1 May timeframe
>>
>> I'd like for the next release (Beta-1) to be our last major feature
>> release. We'll shoot for early May as.  I personally will be disrupted
>> 1-2 weeks because of Red Hat Summit/DevNation
>>
>> Must Have:
>>
>> * Fine grain import/export of keycloak store
>> * LDAP/AD support
>> * Audit Log
>> * Acct Service oauth revocation
>> * Social login remember me
>> * Multi-tenant adapter abilities (for Travis)
>> * Any bootstrap requirements Aerogear needs
>> * Admin console needs to be rebrandable and support different themes.
>> This is an Aerogear requirement
>> * Server needs to be able to run on Resteasy 2.3.6 (EAP 6.x).  A must if
>> we want to get keycloak into EAP through UPS.
>>
>> Would like to have:
>> * Jira adapter.  Have a good idea on how to implement, just need to find
>> the time or a volunteer.
>> * Tomcat, Jetty adapters
>> * Access control by IP Address and user geo location.  i.e. block users
>> from logging in from China, or warn them.  Google does a warning if
>> somebody logged into your account from China. Its how I found out how
>> somebody hacked my account a few years ago.  i have a pretty good idea
>> on how to implement this, just need to find the time or a volunteer.
>>
>>
>> Anything major I'm missing?
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Mar 14 09:12:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 14 Mar 2014 09:12:38 -0400 (EDT)
Subject: [keycloak-dev] LDAP integration
In-Reply-To: <1496286306.27487718.1394802479721.JavaMail.zimbra@redhat.com>
Message-ID: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>

For the first round of LDAP integration we will only focus on authenticating with LDAP.

This will work by adding an Authentication SPI. It will provide two methods, verify user password and update user password. We'll have two implementations of this, Keycloak Model and LDAP (via PicketLink). 

It should be possible to configure which Authentication SPI provider is used by a Realm through the admin console. This will include setting up configuration for the LDAP server.

Second round (which will have a low priority for beta1, so will most likely be postponed to after the 1.0.Final) will be to add a Sync SPI. This will support one-way and two-way of syncing data from an external resource into the Keycloak model. It will support resource that allows registering listeners for events (for near real-time syncing) as well as interval based pulling when this is not possible.


JIRA issue for this is: https://issues.jboss.org/browse/KEYCLOAK-316

From bburke at redhat.com  Fri Mar 14 09:15:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Mar 2014 09:15:19 -0400
Subject: [keycloak-dev] next release Beta 1 May timeframe
In-Reply-To: <5322D17D.5010307@redhat.com>
References: <5321D222.9070508@redhat.com>
	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
	<5322D17D.5010307@redhat.com>
Message-ID: <532300E7.8060407@redhat.com>



On 3/14/2014 5:53 AM, Marek Posolda wrote:
> I would add to "Must have" this:
> - Secured storage of private keys

Ok.

> - Address issues with "state" on TokenManager and SocialRequestManager
> in memory. Would be useful for clustering, and to avoid memory leak
> issues like https://issues.jboss.org/browse/KEYCLOAK-323
>

we'll address this after beta 1.  For beta 2 and final release I want to 
focus on performance and clustering.

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

From stian at redhat.com  Fri Mar 14 09:19:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 14 Mar 2014 09:19:08 -0400 (EDT)
Subject: [keycloak-dev] Thoughts on integration tests
In-Reply-To: <43186119.27494105.1394802984707.JavaMail.zimbra@redhat.com>
Message-ID: <428011676.27495191.1394803148842.JavaMail.zimbra@redhat.com>

It should be possible to run our testsuite against different containers:

* Basic server - what we have now, for development
* WildFly distribution - run on CI with the appliance-dist
* EAP distribution - run on CI with WAR deployed to EAP
* AS7 distribution - run on CI with WAR deployed to AS7

It would also be nice to be able to run the testsuite when Keycloak is embedded into other projects (AeroGear and LiveOak).

Arquillian has recently released a Undertow container, and they already have containers for all of the above. By moving to Arquillian we should be able to fairly easily support running the testsuite against different containers. It would also make it easier to test the admin console as we'd get support for Graphene2 which makes it a lot easier to test ajax-based web apps.

From bburke at redhat.com  Fri Mar 14 09:32:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Mar 2014 09:32:24 -0400
Subject: [keycloak-dev] Thoughts on integration tests
In-Reply-To: <428011676.27495191.1394803148842.JavaMail.zimbra@redhat.com>
References: <428011676.27495191.1394803148842.JavaMail.zimbra@redhat.com>
Message-ID: <532304E8.5040406@redhat.com>

Considering EAP requirements, we might have to do this sooner rather 
than later.

On 3/14/2014 9:19 AM, Stian Thorgersen wrote:
> It should be possible to run our testsuite against different containers:
>
> * Basic server - what we have now, for development
> * WildFly distribution - run on CI with the appliance-dist
> * EAP distribution - run on CI with WAR deployed to EAP
> * AS7 distribution - run on CI with WAR deployed to AS7
>
> It would also be nice to be able to run the testsuite when Keycloak is embedded into other projects (AeroGear and LiveOak).
>
> Arquillian has recently released a Undertow container, and they already have containers for all of the above. By moving to Arquillian we should be able to fairly easily support running the testsuite against different containers. It would also make it easier to test the admin console as we'd get support for Graphene2 which makes it a lot easier to test ajax-based web apps.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Fri Mar 14 09:35:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 14 Mar 2014 09:35:30 -0400 (EDT)
Subject: [keycloak-dev] Thoughts on integration tests
In-Reply-To: <532304E8.5040406@redhat.com>
References: <428011676.27495191.1394803148842.JavaMail.zimbra@redhat.com>
	<532304E8.5040406@redhat.com>
Message-ID: <228185868.27507241.1394804130380.JavaMail.zimbra@redhat.com>

I can have a look at it next week

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 March, 2014 1:32:24 PM
> Subject: Re: [keycloak-dev] Thoughts on integration tests
> 
> Considering EAP requirements, we might have to do this sooner rather
> than later.
> 
> On 3/14/2014 9:19 AM, Stian Thorgersen wrote:
> > It should be possible to run our testsuite against different containers:
> >
> > * Basic server - what we have now, for development
> > * WildFly distribution - run on CI with the appliance-dist
> > * EAP distribution - run on CI with WAR deployed to EAP
> > * AS7 distribution - run on CI with WAR deployed to AS7
> >
> > It would also be nice to be able to run the testsuite when Keycloak is
> > embedded into other projects (AeroGear and LiveOak).
> >
> > Arquillian has recently released a Undertow container, and they already
> > have containers for all of the above. By moving to Arquillian we should be
> > able to fairly easily support running the testsuite against different
> > containers. It would also make it easier to test the admin console as we'd
> > get support for Graphene2 which makes it a lot easier to test ajax-based
> > web apps.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Mar 14 10:12:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Mar 2014 10:12:20 -0400
Subject: [keycloak-dev] LDAP integration
In-Reply-To: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>
References: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>
Message-ID: <53230E44.7080406@redhat.com>

Don't we need to have LDAP as a user store?  Won't companies have a user 
LDAP store they want to point Keycloak to?  If you have an Auth SPI 
only, then you'll still need to register the users with Keycloak.

On 3/14/2014 9:12 AM, Stian Thorgersen wrote:
> For the first round of LDAP integration we will only focus on authenticating with LDAP.
>
> This will work by adding an Authentication SPI. It will provide two methods, verify user password and update user password. We'll have two implementations of this, Keycloak Model and LDAP (via PicketLink).
>
> It should be possible to configure which Authentication SPI provider is used by a Realm through the admin console. This will include setting up configuration for the LDAP server.
>
> Second round (which will have a low priority for beta1, so will most likely be postponed to after the 1.0.Final) will be to add a Sync SPI. This will support one-way and two-way of syncing data from an external resource into the Keycloak model. It will support resource that allows registering listeners for events (for near real-time syncing) as well as interval based pulling when this is not possible.
>
>
> JIRA issue for this is: https://issues.jboss.org/browse/KEYCLOAK-316
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Fri Mar 14 11:15:26 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 14 Mar 2014 11:15:26 -0400 (EDT)
Subject: [keycloak-dev] LDAP integration
In-Reply-To: <53230E44.7080406@redhat.com>
References: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>
	<53230E44.7080406@redhat.com>
Message-ID: <371746902.27615647.1394810126389.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 March, 2014 2:12:20 PM
> Subject: Re: [keycloak-dev] LDAP integration
> 
> Don't we need to have LDAP as a user store?  Won't companies have a user
> LDAP store they want to point Keycloak to?  If you have an Auth SPI
> only, then you'll still need to register the users with Keycloak.

The idea with the authentication would be similar to social login. On first login a user would be created internally in Keycloak, and there would be a link to the user in LDAP. It would provide us with something relatively simple without the fuzz. Social login requires registration to be enabled for new users, but that shouldn't be required to create users that "links" to an LDAP store.

We can even investigate allowing multiple authentication providers for a single realm. For example if a user exist in Keycloak you can check if there is a LDAP link, if there is authenticate with LDAP, otherwise with Keycloak. If no user exist, check with the other configured authentication providers if one exists.

In the second round we can worry about syncing, or alternatively by using LDAP directly for users/role-mappings. I'm not 100% convinced, but I believe the syncing approach is the simpler and probably better solution to "federation".

> 
> On 3/14/2014 9:12 AM, Stian Thorgersen wrote:
> > For the first round of LDAP integration we will only focus on
> > authenticating with LDAP.
> >
> > This will work by adding an Authentication SPI. It will provide two
> > methods, verify user password and update user password. We'll have two
> > implementations of this, Keycloak Model and LDAP (via PicketLink).
> >
> > It should be possible to configure which Authentication SPI provider is
> > used by a Realm through the admin console. This will include setting up
> > configuration for the LDAP server.
> >
> > Second round (which will have a low priority for beta1, so will most likely
> > be postponed to after the 1.0.Final) will be to add a Sync SPI. This will
> > support one-way and two-way of syncing data from an external resource into
> > the Keycloak model. It will support resource that allows registering
> > listeners for events (for near real-time syncing) as well as interval
> > based pulling when this is not possible.
> >
> >
> > JIRA issue for this is: https://issues.jboss.org/browse/KEYCLOAK-316
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Mar 14 11:21:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Mar 2014 11:21:08 -0400
Subject: [keycloak-dev] LDAP integration
In-Reply-To: <371746902.27615647.1394810126389.JavaMail.zimbra@redhat.com>
References: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>
	<53230E44.7080406@redhat.com>
	<371746902.27615647.1394810126389.JavaMail.zimbra@redhat.com>
Message-ID: <53231E64.8000400@redhat.com>



On 3/14/2014 11:15 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 14 March, 2014 2:12:20 PM
>> Subject: Re: [keycloak-dev] LDAP integration
>>
>> Don't we need to have LDAP as a user store?  Won't companies have a user
>> LDAP store they want to point Keycloak to?  If you have an Auth SPI
>> only, then you'll still need to register the users with Keycloak.
>
> The idea with the authentication would be similar to social login. On first login a user would be created internally in Keycloak, and there would be a link to the user in LDAP. It would provide us with something relatively simple without the fuzz. Social login requires registration to be enabled for new users, but that shouldn't be required to create users that "links" to an LDAP store.
>
> We can even investigate allowing multiple authentication providers for a single realm. For example if a user exist in Keycloak you can check if there is a LDAP link, if there is authenticate with LDAP, otherwise with Keycloak. If no user exist, check with the other configured authentication providers if one exists.
>
> In the second round we can worry about syncing, or alternatively by using LDAP directly for users/role-mappings. I'm not 100% convinced, but I believe the syncing approach is the simpler and probably better solution to "federation".
>

So, all user updates (password, attributes, otp, etc...) will be stored 
in Keycloak and then synced with LDAP?

Bill

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

From stian at redhat.com  Fri Mar 14 11:31:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 14 Mar 2014 11:31:47 -0400 (EDT)
Subject: [keycloak-dev] LDAP integration
In-Reply-To: <53231E64.8000400@redhat.com>
References: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>
	<53230E44.7080406@redhat.com>
	<371746902.27615647.1394810126389.JavaMail.zimbra@redhat.com>
	<53231E64.8000400@redhat.com>
Message-ID: <1619464837.27627350.1394811107845.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 March, 2014 3:21:08 PM
> Subject: Re: [keycloak-dev] LDAP integration
> 
> 
> 
> On 3/14/2014 11:15 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 14 March, 2014 2:12:20 PM
> >> Subject: Re: [keycloak-dev] LDAP integration
> >>
> >> Don't we need to have LDAP as a user store?  Won't companies have a user
> >> LDAP store they want to point Keycloak to?  If you have an Auth SPI
> >> only, then you'll still need to register the users with Keycloak.
> >
> > The idea with the authentication would be similar to social login. On first
> > login a user would be created internally in Keycloak, and there would be a
> > link to the user in LDAP. It would provide us with something relatively
> > simple without the fuzz. Social login requires registration to be enabled
> > for new users, but that shouldn't be required to create users that "links"
> > to an LDAP store.
> >
> > We can even investigate allowing multiple authentication providers for a
> > single realm. For example if a user exist in Keycloak you can check if
> > there is a LDAP link, if there is authenticate with LDAP, otherwise with
> > Keycloak. If no user exist, check with the other configured authentication
> > providers if one exists.
> >
> > In the second round we can worry about syncing, or alternatively by using
> > LDAP directly for users/role-mappings. I'm not 100% convinced, but I
> > believe the syncing approach is the simpler and probably better solution
> > to "federation".
> >
> 
> So, all user updates (password, attributes, otp, etc...) will be stored
> in Keycloak and then synced with LDAP?

Can be yes, the Sync SPI needs to be flexible enough to specify what should be synced. It may also only be a one-way sync. Some examples:

* Full sync with LDAP - if a user is added/changed in Keycloak it will be updated in LDAP, same other way around. This includes everything we can sensibly store in LDAP. It will also sync role mappings.
* Read only sync with LDAP - for whatever reason the admin doesn't want to let Keycloak write back to the LDAP server. In this case we'd read changes from LDAP, but not write changes back.
* Write only of users - for example if an application wants to have user profiles (excluding passwords, otp, etc.) in a relational database that can be queried directly by the application. This can be done by implementing the Sync SPI, and they can obviously change the way a user is represented by transforming it during the sync.

This is most likely a stupid idea, but could we use the same syncing solution to sync between a cache and the db?!?

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

From bburke at redhat.com  Fri Mar 14 11:49:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Mar 2014 11:49:30 -0400
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
References: <5321D222.9070508@redhat.com>
	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
Message-ID: <5323250A.4060808@redhat.com>

FYI Working on Brute force login attack protection today.  Last thing 
I'll do until I spend a week on Resteasy.

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

From bburke at redhat.com  Fri Mar 14 13:40:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Mar 2014 13:40:15 -0400
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <5323250A.4060808@redhat.com>
References: <5321D222.9070508@redhat.com>	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
	<5323250A.4060808@redhat.com>
Message-ID: <53233EFF.6070504@redhat.com>

The only good way to protect against brute force attacks is CAPTCHA or 
IP Address ACLs.  If you implement a delay, you can just have a 
multi-threaded attack.  If you disable the account after a number of 
failed attempts, then you can have a DoS attack and bring down the whole 
site.



On 3/14/2014 11:49 AM, Bill Burke wrote:
> FYI Working on Brute force login attack protection today.  Last thing
> I'll do until I spend a week on Resteasy.
>

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

From bburke at redhat.com  Fri Mar 14 18:01:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Mar 2014 18:01:47 -0400
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <53233EFF.6070504@redhat.com>
References: <5321D222.9070508@redhat.com>	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>	<5323250A.4060808@redhat.com>
	<53233EFF.6070504@redhat.com>
Message-ID: <53237C4B.4090404@redhat.com>

Ugh, seems that Captchas are easily broken too and also cause as much as 
10% loss in leads/users.  I've seen suggestions of a combination of IP 
Address whitelists and blacklists per user and cross user.


1. If a user successfully logs in, add their IP address to the user's 
whitelist.
2. After X failed login attempts per user, set the User's notBefore to 
incrementally higher times on multiple failures.  The notBefore check is 
ignored for IP address on the user's whitelist.

The problem I see with this approach is that the attacker's IP might be 
on the whitelist because of a proxy.  There's also the problem with a 
Gateway/Proxy screwing up the Server's idea of what the client IP is.  I 
know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR".  I'm 
wondering if you can trust the Gateway/Proxy to remove 
"HTTP_X_FORWARDED_FOR" headers sent by the client itself.


Do you think that is good enough?  If the site wants better protection 
then they should add two-factor auth.  When we support certs, they 
should require those too.




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

From stian at redhat.com  Mon Mar 17 05:38:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Mar 2014 05:38:19 -0400 (EDT)
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <53237C4B.4090404@redhat.com>
References: <5321D222.9070508@redhat.com>
	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
	<5323250A.4060808@redhat.com> <53233EFF.6070504@redhat.com>
	<53237C4B.4090404@redhat.com>
Message-ID: <568788053.449728.1395049099530.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 14 March, 2014 10:01:47 PM
> Subject: Re: [keycloak-dev] Brute force attack protection
> 
> Ugh, seems that Captchas are easily broken too and also cause as much as
> 10% loss in leads/users.  I've seen suggestions of a combination of IP
> Address whitelists and blacklists per user and cross user.
> 
> 
> 1. If a user successfully logs in, add their IP address to the user's
> whitelist.
> 2. After X failed login attempts per user, set the User's notBefore to
> incrementally higher times on multiple failures.  The notBefore check is
> ignored for IP address on the user's whitelist.
> 
> The problem I see with this approach is that the attacker's IP might be
> on the whitelist because of a proxy.  There's also the problem with a
> Gateway/Proxy screwing up the Server's idea of what the client IP is.  I
> know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR".  I'm
> wondering if you can trust the Gateway/Proxy to remove
> "HTTP_X_FORWARDED_FOR" headers sent by the client itself.

Wouldn't a blacklist be better? If a user fails to login from a certain IP address N times add the IP to a blacklist?

I can see a few issues with a whitelist:

* Shared IP/NAT
* Public networks (anyone at a Starbucks is on the whitelist)
* Dynamic IP addresses (home broadband)

> 
> 
> Do you think that is good enough?  If the site wants better protection
> then they should add two-factor auth.  When we support certs, they
> should require those too.
> 
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Mon Mar 17 09:06:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 17 Mar 2014 09:06:39 -0400
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <568788053.449728.1395049099530.JavaMail.zimbra@redhat.com>
References: <5321D222.9070508@redhat.com>
	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
	<5323250A.4060808@redhat.com> <53233EFF.6070504@redhat.com>
	<53237C4B.4090404@redhat.com>
	<568788053.449728.1395049099530.JavaMail.zimbra@redhat.com>
Message-ID: <5326F35F.7070002@redhat.com>



On 3/17/2014 5:38 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 14 March, 2014 10:01:47 PM
>> Subject: Re: [keycloak-dev] Brute force attack protection
>>
>> Ugh, seems that Captchas are easily broken too and also cause as much as
>> 10% loss in leads/users.  I've seen suggestions of a combination of IP
>> Address whitelists and blacklists per user and cross user.
>>
>>
>> 1. If a user successfully logs in, add their IP address to the user's
>> whitelist.
>> 2. After X failed login attempts per user, set the User's notBefore to
>> incrementally higher times on multiple failures.  The notBefore check is
>> ignored for IP address on the user's whitelist.
>>
>> The problem I see with this approach is that the attacker's IP might be
>> on the whitelist because of a proxy.  There's also the problem with a
>> Gateway/Proxy screwing up the Server's idea of what the client IP is.  I
>> know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR".  I'm
>> wondering if you can trust the Gateway/Proxy to remove
>> "HTTP_X_FORWARDED_FOR" headers sent by the client itself.
>
> Wouldn't a blacklist be better? If a user fails to login from a certain IP address N times add the IP to a blacklist?
>
> I can see a few issues with a whitelist:
>
> * Shared IP/NAT
> * Public networks (anyone at a Starbucks is on the whitelist)
> * Dynamic IP addresses (home broadband)
>

Did a bit more research.

Blacklist has the same issues as a whitelist.  What I think I'm going to 
do is if there is a failure, wait to respond to the client for N 
seconds.  This let's successful logins immediately, but delays responses 
from a failure.  I'll also automatically wait N number of seconds if the 
last failure was not that far back.  (1 secs?  2 secs?)

This could cause a DoS, but could be mitigated greatly if we used Async 
HTTP.  Unfortunately, I believe EAP has a race condition with Async 
HTTP.  Need to find out if it was fixed.

We'll also keep a log of failures by IP that can be displayed in the 
admin console.  Allow the admin to create blacklists/whitelists.  Allow 
the admin to specify if headers like "X-Forwarded-For" can be trusted. 
Allow admins to set up blocks/warnings by country IP.

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

From stian at redhat.com  Mon Mar 17 09:54:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Mar 2014 09:54:31 -0400 (EDT)
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <5326F35F.7070002@redhat.com>
References: <5321D222.9070508@redhat.com>
	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
	<5323250A.4060808@redhat.com> <53233EFF.6070504@redhat.com>
	<53237C4B.4090404@redhat.com>
	<568788053.449728.1395049099530.JavaMail.zimbra@redhat.com>
	<5326F35F.7070002@redhat.com>
Message-ID: <2028140085.613426.1395064471401.JavaMail.zimbra@redhat.com>

We could do the sleep on the client side. We'd set a flag on the account saying it's disabled until some time in the future. If an account is locked we can display a page that says wait N seconds (or something), and after N seconds redirect redirect to login form using meta refresh.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 17 March, 2014 1:06:39 PM
> Subject: Re: [keycloak-dev] Brute force attack protection
> 
> 
> 
> On 3/17/2014 5:38 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 14 March, 2014 10:01:47 PM
> >> Subject: Re: [keycloak-dev] Brute force attack protection
> >>
> >> Ugh, seems that Captchas are easily broken too and also cause as much as
> >> 10% loss in leads/users.  I've seen suggestions of a combination of IP
> >> Address whitelists and blacklists per user and cross user.
> >>
> >>
> >> 1. If a user successfully logs in, add their IP address to the user's
> >> whitelist.
> >> 2. After X failed login attempts per user, set the User's notBefore to
> >> incrementally higher times on multiple failures.  The notBefore check is
> >> ignored for IP address on the user's whitelist.
> >>
> >> The problem I see with this approach is that the attacker's IP might be
> >> on the whitelist because of a proxy.  There's also the problem with a
> >> Gateway/Proxy screwing up the Server's idea of what the client IP is.  I
> >> know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR".  I'm
> >> wondering if you can trust the Gateway/Proxy to remove
> >> "HTTP_X_FORWARDED_FOR" headers sent by the client itself.
> >
> > Wouldn't a blacklist be better? If a user fails to login from a certain IP
> > address N times add the IP to a blacklist?
> >
> > I can see a few issues with a whitelist:
> >
> > * Shared IP/NAT
> > * Public networks (anyone at a Starbucks is on the whitelist)
> > * Dynamic IP addresses (home broadband)
> >
> 
> Did a bit more research.
> 
> Blacklist has the same issues as a whitelist.  What I think I'm going to
> do is if there is a failure, wait to respond to the client for N
> seconds.  This let's successful logins immediately, but delays responses
> from a failure.  I'll also automatically wait N number of seconds if the
> last failure was not that far back.  (1 secs?  2 secs?)
> 
> This could cause a DoS, but could be mitigated greatly if we used Async
> HTTP.  Unfortunately, I believe EAP has a race condition with Async
> HTTP.  Need to find out if it was fixed.
> 
> We'll also keep a log of failures by IP that can be displayed in the
> admin console.  Allow the admin to create blacklists/whitelists.  Allow
> the admin to specify if headers like "X-Forwarded-For" can be trusted.
> Allow admins to set up blocks/warnings by country IP.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Mon Mar 17 10:06:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 17 Mar 2014 10:06:43 -0400
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <2028140085.613426.1395064471401.JavaMail.zimbra@redhat.com>
References: <5321D222.9070508@redhat.com>
	<1210306133.26838385.1394727615287.JavaMail.zimbra@redhat.com>
	<5323250A.4060808@redhat.com> <53233EFF.6070504@redhat.com>
	<53237C4B.4090404@redhat.com>
	<568788053.449728.1395049099530.JavaMail.zimbra@redhat.com>
	<5326F35F.7070002@redhat.com>
	<2028140085.613426.1395064471401.JavaMail.zimbra@redhat.com>
Message-ID: <53270173.1070705@redhat.com>



On 3/17/2014 9:54 AM, Stian Thorgersen wrote:
> We could do the sleep on the client side. We'd set a flag on the account saying it's disabled until some time in the future. If an account is locked we can display a page that says wait N seconds (or something), and after N seconds redirect redirect to login form using meta refresh.
>

This creates a very easy DoS opportunity.


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

From stian at redhat.com  Mon Mar 17 10:13:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Mar 2014 10:13:13 -0400 (EDT)
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <53270173.1070705@redhat.com>
References: <5321D222.9070508@redhat.com> <5323250A.4060808@redhat.com>
	<53233EFF.6070504@redhat.com> <53237C4B.4090404@redhat.com>
	<568788053.449728.1395049099530.JavaMail.zimbra@redhat.com>
	<5326F35F.7070002@redhat.com>
	<2028140085.613426.1395064471401.JavaMail.zimbra@redhat.com>
	<53270173.1070705@redhat.com>
Message-ID: <2146158980.631916.1395065593906.JavaMail.zimbra@redhat.com>

For a single user yes. Is that a big problem though?

If you sleep on the server you'd be able to do a DoS on the whole server (even if async) with a single machine.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 17 March, 2014 2:06:43 PM
> Subject: Re: [keycloak-dev] Brute force attack protection
> 
> 
> 
> On 3/17/2014 9:54 AM, Stian Thorgersen wrote:
> > We could do the sleep on the client side. We'd set a flag on the account
> > saying it's disabled until some time in the future. If an account is
> > locked we can display a page that says wait N seconds (or something), and
> > after N seconds redirect redirect to login form using meta refresh.
> >
> 
> This creates a very easy DoS opportunity.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Mon Mar 17 10:23:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 17 Mar 2014 10:23:42 -0400 (EDT)
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <2146158980.631916.1395065593906.JavaMail.zimbra@redhat.com>
References: <5321D222.9070508@redhat.com> <53233EFF.6070504@redhat.com>
	<53237C4B.4090404@redhat.com>
	<568788053.449728.1395049099530.JavaMail.zimbra@redhat.com>
	<5326F35F.7070002@redhat.com>
	<2028140085.613426.1395064471401.JavaMail.zimbra@redhat.com>
	<53270173.1070705@redhat.com>
	<2146158980.631916.1395065593906.JavaMail.zimbra@redhat.com>
Message-ID: <437006521.645529.1395066222844.JavaMail.zimbra@redhat.com>

Another thing, if someone really want to brute-force a specific account and they have a botnet of 100K+ machines, a simple sleep of a few seconds isn't going to stop them. I think the only way of doing that is to lock the account after N attempts.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 17 March, 2014 2:13:13 PM
> Subject: Re: [keycloak-dev] Brute force attack protection
> 
> For a single user yes. Is that a big problem though?
> 
> If you sleep on the server you'd be able to do a DoS on the whole server
> (even if async) with a single machine.
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Monday, 17 March, 2014 2:06:43 PM
> > Subject: Re: [keycloak-dev] Brute force attack protection
> > 
> > 
> > 
> > On 3/17/2014 9:54 AM, Stian Thorgersen wrote:
> > > We could do the sleep on the client side. We'd set a flag on the account
> > > saying it's disabled until some time in the future. If an account is
> > > locked we can display a page that says wait N seconds (or something), and
> > > after N seconds redirect redirect to login form using meta refresh.
> > >
> > 
> > This creates a very easy DoS opportunity.
> > 
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Mon Mar 17 10:28:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 17 Mar 2014 10:28:57 -0400
Subject: [keycloak-dev] Brute force attack protection
In-Reply-To: <2146158980.631916.1395065593906.JavaMail.zimbra@redhat.com>
References: <5321D222.9070508@redhat.com> <5323250A.4060808@redhat.com>
	<53233EFF.6070504@redhat.com> <53237C4B.4090404@redhat.com>
	<568788053.449728.1395049099530.JavaMail.zimbra@redhat.com>
	<5326F35F.7070002@redhat.com>
	<2028140085.613426.1395064471401.JavaMail.zimbra@redhat.com>
	<53270173.1070705@redhat.com>
	<2146158980.631916.1395065593906.JavaMail.zimbra@redhat.com>
Message-ID: <532706A9.60304@redhat.com>



On 3/17/2014 10:13 AM, Stian Thorgersen wrote:
> For a single user yes. Is that a big problem though?
>

I don't know.  All the hacker needs to know is a list of emails and 
could lock down a large set of users.  Plus the users being hacked are 
also locked out.


> If you sleep on the server you'd be able to do a DoS on the whole server (even if async) with a single machine.
>

Ugh, I guess the hacker could just ignore responses that are blocking.


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

From stian at redhat.com  Tue Mar 18 06:54:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Mar 2014 06:54:48 -0400 (EDT)
Subject: [keycloak-dev] Beta1 page
Message-ID: <1959045822.1296498.1395140088251.JavaMail.zimbra@redhat.com>

Added https://github.com/keycloak/keycloak/wiki/Beta1 as a place to track must have's and nice to have's for beta1

From bburke at redhat.com  Tue Mar 18 10:52:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 18 Mar 2014 10:52:43 -0400
Subject: [keycloak-dev] autotesting keycloak.js
Message-ID: <53285DBB.5080602@redhat.com>

Can it be autotested with selenium?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Mar 18 12:00:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Mar 2014 12:00:52 -0400 (EDT)
Subject: [keycloak-dev] autotesting keycloak.js
In-Reply-To: <53285DBB.5080602@redhat.com>
References: <53285DBB.5080602@redhat.com>
Message-ID: <95812863.1502882.1395158452337.JavaMail.zimbra@redhat.com>

That's the plan yes. If we start using Arquillian/Graphene it should be simpler.

By the way I've just pushed a lot of improvements to keycloak.js, it now loads config from keycloak.js and also uses promises. There's also a new js-console in examples. I'll update the documentation soon.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 March, 2014 2:52:43 PM
> Subject: [keycloak-dev] autotesting keycloak.js
> 
> Can it be autotested with selenium?
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Mar 18 12:05:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 18 Mar 2014 12:05:34 -0400 (EDT)
Subject: [keycloak-dev] autotesting keycloak.js
In-Reply-To: <95812863.1502882.1395158452337.JavaMail.zimbra@redhat.com>
References: <53285DBB.5080602@redhat.com>
	<95812863.1502882.1395158452337.JavaMail.zimbra@redhat.com>
Message-ID: <1112515112.1505647.1395158734773.JavaMail.zimbra@redhat.com>

Loads config from keycloak.json that is....

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 March, 2014 4:00:52 PM
> Subject: Re: [keycloak-dev] autotesting keycloak.js
> 
> That's the plan yes. If we start using Arquillian/Graphene it should be
> simpler.
> 
> By the way I've just pushed a lot of improvements to keycloak.js, it now
> loads config from keycloak.js and also uses promises. There's also a new
> js-console in examples. I'll update the documentation soon.
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 18 March, 2014 2:52:43 PM
> > Subject: [keycloak-dev] autotesting keycloak.js
> > 
> > Can it be autotested with selenium?
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From corinnekrych at gmail.com  Wed Mar 19 06:05:29 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Wed, 19 Mar 2014 11:05:29 +0100
Subject: [keycloak-dev] [aerogear-dev] Keycloak adapters for iOS and
	Android
In-Reply-To: <CAKjsGbukxfA2W9rDQ3sZMZxVbrfug=kj-Azp0Wypv3XVRruRwg@mail.gmail.com>
References: <805376679.1293116.1395139456827.JavaMail.zimbra@redhat.com>
	<1413826749.1296233.1395140014298.JavaMail.zimbra@redhat.com>
	<CAKjsGbukxfA2W9rDQ3sZMZxVbrfug=kj-Azp0Wypv3XVRruRwg@mail.gmail.com>
Message-ID: <AF35CD42-E3EF-4866-A25D-6EDBEEB63EE0@gmail.com>

Hello Stian

KC adapter is planned for our iOS 1.6 release (end of June) as pointed out by abstract, it?s in our roadmap. Once 1.5 is out (end of this week), we?ll start 1.6 and work this adapter.

As for Android, we have our ios-cookbook[1], we can find a sample that fit close to your sample app. No worries. We also have a JIRA ticket to track progress[2].
++
Corinne
[1] https://github.com/aerogear/aerogear-ios-cookbook
[2] https://issues.jboss.org/browse/AGIOS-178

On 18 Mar 2014, at 12:29, Daniel Passos <daniel at passos.me> wrote:

> Hi Stian,
> 
> Answers inline
> 
> On Tue, Mar 18, 2014 at 7:53 AM, Stian Thorgersen <stian at redhat.com> wrote:
> We're aiming to release beta1 of Keycloak in beginning of May. It would be great to have basic iOS and Android examples added to our demo. With that in mind I have a couple of question:
> 
> * Any chance anyone from the AeroGear team could contribute an iOS example? Something that works together with our current demo would be great, login with Keycloak and fetch/display customers list from the server is sufficient (same features as customer-portal and customer-portal-js in our demo). It would also be nice to have a small section on how to use it added to our documentation.
> * Do you have an ETA when Android adapter will be ready?
> 
> Yes, we have already started working on it. We'll postpone our 1.4 release (scheduled for mid March to mid April ) to include KC adapter see last meeting notes[1]
>  
> * Same as for iOS, any chance to get some help with an Android example and documentation?
> 
> Of course. Ping me when you need. Btw, we'll add it on our cookbook app[2]
>  
> Cheers,
> Stian
> 
> [1] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-03-17-13.47.html
> [2] https://github.com/aerogear/aerogear-android-cookbook
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



From stian at redhat.com  Wed Mar 19 13:01:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Mar 2014 13:01:24 -0400 (EDT)
Subject: [keycloak-dev] [aerogear-dev] Keycloak adapters for iOS
	and	Android
In-Reply-To: <AF35CD42-E3EF-4866-A25D-6EDBEEB63EE0@gmail.com>
References: <805376679.1293116.1395139456827.JavaMail.zimbra@redhat.com>
	<1413826749.1296233.1395140014298.JavaMail.zimbra@redhat.com>
	<CAKjsGbukxfA2W9rDQ3sZMZxVbrfug=kj-Azp0Wypv3XVRruRwg@mail.gmail.com>
	<AF35CD42-E3EF-4866-A25D-6EDBEEB63EE0@gmail.com>
Message-ID: <299704101.2334992.1395248484319.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Corinne Krych" <corinnekrych at gmail.com>
> To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 19 March, 2014 10:05:29 AM
> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak adapters for iOS and	Android
> 
> Hello Stian
> 
> KC adapter is planned for our iOS 1.6 release (end of June) as pointed out by
> abstract, it?s in our roadmap. Once 1.5 is out (end of this week), we?ll
> start 1.6 and work this adapter.

Great, please keep me updated on the progress and if there's any issues you have with Keycloak :)

> 
> As for Android, we have our ios-cookbook[1], we can find a sample that fit
> close to your sample app. No worries. We also have a JIRA ticket to track
> progress[2].
> ++
> Corinne
> [1] https://github.com/aerogear/aerogear-ios-cookbook
> [2] https://issues.jboss.org/browse/AGIOS-178
> 
> On 18 Mar 2014, at 12:29, Daniel Passos <daniel at passos.me> wrote:
> 
> > Hi Stian,
> > 
> > Answers inline
> > 
> > On Tue, Mar 18, 2014 at 7:53 AM, Stian Thorgersen <stian at redhat.com> wrote:
> > We're aiming to release beta1 of Keycloak in beginning of May. It would be
> > great to have basic iOS and Android examples added to our demo. With that
> > in mind I have a couple of question:
> > 
> > * Any chance anyone from the AeroGear team could contribute an iOS example?
> > Something that works together with our current demo would be great, login
> > with Keycloak and fetch/display customers list from the server is
> > sufficient (same features as customer-portal and customer-portal-js in our
> > demo). It would also be nice to have a small section on how to use it
> > added to our documentation.
> > * Do you have an ETA when Android adapter will be ready?
> > 
> > Yes, we have already started working on it. We'll postpone our 1.4 release
> > (scheduled for mid March to mid April ) to include KC adapter see last
> > meeting notes[1]
> >  
> > * Same as for iOS, any chance to get some help with an Android example and
> > documentation?
> > 
> > Of course. Ping me when you need. Btw, we'll add it on our cookbook app[2]
> >  
> > Cheers,
> > Stian
> > 
> > [1]
> > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-03-17-13.47.html
> > [2] https://github.com/aerogear/aerogear-android-cookbook
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From stian at redhat.com  Wed Mar 19 13:09:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 19 Mar 2014 13:09:45 -0400 (EDT)
Subject: [keycloak-dev] Updates to keycloak.js including support for Cordova
In-Reply-To: <1438884891.2342685.1395248664607.JavaMail.zimbra@redhat.com>
Message-ID: <1407429932.2354420.1395248985560.JavaMail.zimbra@redhat.com>

I've polished keycloak.js and also added a few more features to it:

* Cordova support
* Account management support
* Load config from keycloak.json
* Added a bunch of events (onAuthSuccess, onAuthError, onAuthRefreshSuccess, onAuthRefreshError, onReady)
* Async methods now return promise (init, updateToken, loadProfile)

I need to update the documentation, but there's two new examples:

* example/js-console - exposes pretty much all functionality in the js lib
* example/cordova - basic Cordova example (tested with Android phone and emulator)

From adrian.mitev at gmail.com  Thu Mar 20 06:47:44 2014
From: adrian.mitev at gmail.com (Adrian Mitev)
Date: Thu, 20 Mar 2014 12:47:44 +0200
Subject: [keycloak-dev] Features whishlist
Message-ID: <CAN_QJsEbBL1X7nGeFxARFchqus67uQ51FBF9pnXNJBhVuSNthg@mail.gmail.com>

Hi guys! I'm very interested in Keycloak and would like to share with you
some ideas that come from user requirements I currently have or had in the
past that you may find useful to add in Keycloak.
* Automatically revoke access to user account after a (configurable) number
of invalid sign-on passwords until the system administrator has unlocked
the account or automatically after an administrator-defined interval - I
know that with such feature an attacker could lock user accounts by simply
knowing usernames/emails. However I have a case of an Intranet application
that is accessible only inside the company and could trace such attackers
by their ip addresses.
* Record and report (i.e. email sending) on failed login attempts outlining
* Force password changes at regular (configurable) intervals or
* Automatically reset the password and send a new one to the user via email
* Can ensure that the new password has not been used before in a number
(configurable) of password changes
* Login using digital signature in a smart card or p12 file
* Security questions for password recovery

Other that I found as issues in other Identity Providers
* Support many accounts (~10K) within a reasonable amount of time
* When providing an authentication client (maven dependency) add only the
needed set of dependencies. I know this sounds silly but I have experience
with a client library provided by the Identity Provider that had a compile
dependency to apache ant...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140320/52e5e04f/attachment-0001.html 

From bburke at redhat.com  Thu Mar 20 09:22:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Mar 2014 09:22:11 -0400
Subject: [keycloak-dev] Features whishlist
In-Reply-To: <CAN_QJsEbBL1X7nGeFxARFchqus67uQ51FBF9pnXNJBhVuSNthg@mail.gmail.com>
References: <CAN_QJsEbBL1X7nGeFxARFchqus67uQ51FBF9pnXNJBhVuSNthg@mail.gmail.com>
Message-ID: <532AEB83.80608@redhat.com>



On 3/20/2014 6:47 AM, Adrian Mitev wrote:
> Hi guys! I'm very interested in Keycloak and would like to share with
> you some ideas that come from user requirements I currently have or had
> in the past that you may find useful to add in Keycloak.
> * Automatically revoke access to user account after a (configurable)
> number of invalid sign-on passwords until the system administrator has
> unlocked the account or automatically after an administrator-defined
> interval - I know that with such feature an attacker could lock user
> accounts by simply knowing usernames/emails. However I have a case of an
> Intranet application that is accessible only inside the company and
> could trace such attackers by their ip addresses.

Working on Brute force detection now.  First iteration will increasingly 
add a "not before" time on successive login failures.  Second iteration 
will include IP address options.

> * Record and report (i.e. email sending) on failed login attempts outlining
> * Force password changes at regular (configurable) intervals or
> * Automatically reset the password and send a new one to the user via email
> * Can ensure that the new password has not been used before in a number
> (configurable) of password changes
> * Login using digital signature in a smart card or p12 file

This something different than OTP?

> * Security questions for password recovery
>
> Other that I found as issues in other Identity Providers
> * Support many accounts (~10K) within a reasonable amount of time
> * When providing an authentication client (maven dependency) add only
> the needed set of dependencies. I know this sounds silly but I have
> experience with a client library provided by the Identity Provider that
> had a compile dependency to apache ant...
>

So far our adapters are installed once onto the app server.

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

From adrian.mitev at gmail.com  Thu Mar 20 09:47:22 2014
From: adrian.mitev at gmail.com (Adrian Mitev)
Date: Thu, 20 Mar 2014 15:47:22 +0200
Subject: [keycloak-dev] Features whishlist
In-Reply-To: <532AEB83.80608@redhat.com>
References: <CAN_QJsEbBL1X7nGeFxARFchqus67uQ51FBF9pnXNJBhVuSNthg@mail.gmail.com>
	<532AEB83.80608@redhat.com>
Message-ID: <CAN_QJsHtXoBG1-jk8AJ0BAUYH3JVbN23j=+2y=7xV=eDKc76fw@mail.gmail.com>

On Thu, Mar 20, 2014 at 3:22 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 3/20/2014 6:47 AM, Adrian Mitev wrote:
> > Hi guys! I'm very interested in Keycloak and would like to share with
> > you some ideas that come from user requirements I currently have or had
> > in the past that you may find useful to add in Keycloak.
> > * Automatically revoke access to user account after a (configurable)
> > number of invalid sign-on passwords until the system administrator has
> > unlocked the account or automatically after an administrator-defined
> > interval - I know that with such feature an attacker could lock user
> > accounts by simply knowing usernames/emails. However I have a case of an
> > Intranet application that is accessible only inside the company and
> > could trace such attackers by their ip addresses.
>
> Working on Brute force detection now.  First iteration will increasingly
> add a "not before" time on successive login failures.  Second iteration
> will include IP address options.
>
> > * Record and report (i.e. email sending) on failed login attempts
> outlining
> > * Force password changes at regular (configurable) intervals or
> > * Automatically reset the password and send a new one to the user via
> email
> > * Can ensure that the new password has not been used before in a number
> > (configurable) of password changes
> > * Login using digital signature in a smart card or p12 file
>
> This something different than OTP?
>
A customer company has a policy that a password for user account should be
changed every week. This counts for special type of users that access more
sensitive information.


>
> > * Security questions for password recovery
> >
> > Other that I found as issues in other Identity Providers
> > * Support many accounts (~10K) within a reasonable amount of time
> > * When providing an authentication client (maven dependency) add only
> > the needed set of dependencies. I know this sounds silly but I have
> > experience with a client library provided by the Identity Provider that
> > had a compile dependency to apache ant...
> >
>
> So far our adapters are installed once onto the app server.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140320/205711f0/attachment.html 

From stian at redhat.com  Thu Mar 20 12:59:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 20 Mar 2014 12:59:50 -0400 (EDT)
Subject: [keycloak-dev] Audit
In-Reply-To: <489413335.3215015.1395334602158.JavaMail.zimbra@redhat.com>
Message-ID: <1296197794.3219626.1395334790802.JavaMail.zimbra@redhat.com>

I plan to start work on the audit log tomorrow. Including some support for admins to view recent log, users to view recent activity for their accounts, and email notifications during certain events.

From stian at redhat.com  Fri Mar 21 06:54:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 21 Mar 2014 06:54:45 -0400 (EDT)
Subject: [keycloak-dev] Realm option to enable/disable grants/access
Message-ID: <2078587511.3542089.1395399285684.JavaMail.zimbra@redhat.com>

I think we should add a realm option to enable 'grants/access', by default it should be disabled.

From mposolda at redhat.com  Mon Mar 24 19:20:44 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 25 Mar 2014 00:20:44 +0100
Subject: [keycloak-dev] LDAP integration
In-Reply-To: <1619464837.27627350.1394811107845.JavaMail.zimbra@redhat.com>
References: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>	<53230E44.7080406@redhat.com>	<371746902.27615647.1394810126389.JavaMail.zimbra@redhat.com>	<53231E64.8000400@redhat.com>
	<1619464837.27627350.1394811107845.JavaMail.zimbra@redhat.com>
Message-ID: <5330BDCC.2010405@redhat.com>

Hi,

I've sent PR https://github.com/keycloak/keycloak/pull/302 with first 
version of Authentication SPI. Some key features:
- Authentication SPI is used for validation of username+password and 
also for password updates. So all existing components like 
AuthenticationManager and AccountService are now calling Authentication 
SPI instead of directly calling realm.validatePassword or 
realm.updateCredentials.

- Currently used just for username+password authentication. TOTP is 
still using RealmModel directly.

- I've added 3 implementations of Authentication SPI.
-- Model - This just delegates to realm.validatePassword and 
realm.updatePassword, so it's defacto the same stuff what we have now. 
This is the default implementation, which is used if no others are 
configured
-- ExternalModel -- This delegates authentication to "external" realm. 
In other words, user will be able to authenticate in RealmA with 
credentials from RealmB.
-- Picketlink -- This delegates authentication to Picketlink 
IdentityManager. I've added another abstraction 
PartitionManagerProvider, so it's possible to obtain Picketlink base 
class PartitionManager from various sources (for example from Picketlink 
subsystem). Default and only implementation of PartitionManagerProvider 
is initializing Picketlink with Ldap Identity store. Configuration of 
Ldap server is obtained from realm.

- Propagation of identities: If user authenticated with Authentication 
SPI doesn't yet exists in realm, he will be "synced" and automatically 
created into realm. So for example if you configure Picketlink 
AuthenticationProvider and corporate LDAP with 5k users and then you 
authenticate with your corporate username/password, your user account is 
automatically created in realm and also all basic attributes (firstName, 
lastName, email) are retrieved from LDAP server, or from external-realm 
or whatever other authentication provider provides.

- For update password, it's possible to configure that password will be 
updated just in some authentication providers. So for example, you can 
have read-only LDAP, which is used just for authentication users, but 
they can't update password here. Instead password might be updated just 
in "model" based Authentication Provider and synced into Keycloak DB, so 
next time user is able to authenticate with this changed password from 
Keycloak DB instead of the Ldap password.

- Configuration looks like this:

"authenticationProviders": [
     {
         "providerName": "model",
     "passwordUpdateSupported": true
     },
     {
         "providerName": "externalModel",
         "passwordUpdateSupported": false,
         "config": {
             "externalRealmId": "trustedRealm"
         }
     },
     {
         "providerName": "picketlink",
         "passwordUpdateSupported": true
     }
],


Picketlink provider doesn't have any configuration as it's currently 
automatically configured with LDAP server, which is configured for realm 
like this:

"ldapServer": {
     "connectionUrl": "ldap://localhost:10389",
     "baseDn": "dc=keycloak,dc=org",
     "userDnSuffix": "ou=People,dc=keycloak,dc=org",
     "bindDn": "uid=admin,ou=system",
     "bindCredential": "secret"
},

LDAP configuration is in separate "ldapServer" element as same LDAP 
config (and same PartitionManager) will be used for Authentication SPI 
and in the future for other things (like Sync SPI)


- Before this, we had just KeycloakSessionFactory as only 
application-scoped component. But with adding Authentication SPI and 
Picketlink+LDAP support, we may need more components (for example IDM 
PartitionManager, which is intended to be application-scoped component). 
Hence I've introduced KeycloakRegistry, which is simple Map of 
application-scoped components. And it's attribute ServletContext instead 
of KeycloakSessionFactory. Currently this registry contains just 
KeycloakSessionFactory and PartitionManagerRegistry (in case that LDAP 
is used). It's quite simple, but sufficient for current needs...

- For LDAP testing, I've reused some stuff from Picketlink+Picketbox and 
added embedded ApacheDS server into unit tests and testsuite.

- If you're ok with everything and merge this, I can follow with adding 
support for configuration Authentication providers and LDAP into admin 
console (right now it's possible just through JSON). And then possibly 
Sync SPI for the batch syncing of stuff from/to Sync providers (like 
LDAP server) or other Beta1 priorities from the wishlist :)

Cheers,
Marek

On 14.3.2014 16:31, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 14 March, 2014 3:21:08 PM
>> Subject: Re: [keycloak-dev] LDAP integration
>>
>>
>>
>> On 3/14/2014 11:15 AM, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 14 March, 2014 2:12:20 PM
>>>> Subject: Re: [keycloak-dev] LDAP integration
>>>>
>>>> Don't we need to have LDAP as a user store?  Won't companies have a user
>>>> LDAP store they want to point Keycloak to?  If you have an Auth SPI
>>>> only, then you'll still need to register the users with Keycloak.
>>> The idea with the authentication would be similar to social login. On first
>>> login a user would be created internally in Keycloak, and there would be a
>>> link to the user in LDAP. It would provide us with something relatively
>>> simple without the fuzz. Social login requires registration to be enabled
>>> for new users, but that shouldn't be required to create users that "links"
>>> to an LDAP store.
>>>
>>> We can even investigate allowing multiple authentication providers for a
>>> single realm. For example if a user exist in Keycloak you can check if
>>> there is a LDAP link, if there is authenticate with LDAP, otherwise with
>>> Keycloak. If no user exist, check with the other configured authentication
>>> providers if one exists.
>>>
>>> In the second round we can worry about syncing, or alternatively by using
>>> LDAP directly for users/role-mappings. I'm not 100% convinced, but I
>>> believe the syncing approach is the simpler and probably better solution
>>> to "federation".
>>>
>> So, all user updates (password, attributes, otp, etc...) will be stored
>> in Keycloak and then synced with LDAP?
> Can be yes, the Sync SPI needs to be flexible enough to specify what should be synced. It may also only be a one-way sync. Some examples:
>
> * Full sync with LDAP - if a user is added/changed in Keycloak it will be updated in LDAP, same other way around. This includes everything we can sensibly store in LDAP. It will also sync role mappings.
> * Read only sync with LDAP - for whatever reason the admin doesn't want to let Keycloak write back to the LDAP server. In this case we'd read changes from LDAP, but not write changes back.
> * Write only of users - for example if an application wants to have user profiles (excluding passwords, otp, etc.) in a relational database that can be queried directly by the application. This can be done by implementing the Sync SPI, and they can obviously change the way a user is represented by transforming it during the sync.
>
> This is most likely a stupid idea, but could we use the same syncing solution to sync between a cache and the db?!?
>
>> Bill
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue Mar 25 11:58:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 25 Mar 2014 11:58:36 -0400
Subject: [keycloak-dev] LDAP integration
In-Reply-To: <5330BDCC.2010405@redhat.com>
References: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>	<53230E44.7080406@redhat.com>	<371746902.27615647.1394810126389.JavaMail.zimbra@redhat.com>	<53231E64.8000400@redhat.com>	<1619464837.27627350.1394811107845.JavaMail.zimbra@redhat.com>
	<5330BDCC.2010405@redhat.com>
Message-ID: <5331A7AC.8020102@redhat.com>

Getting build failures in JPA for LDAP test

On 3/24/2014 7:20 PM, Marek Posolda wrote:
> Hi,
>
> I've sent PR https://github.com/keycloak/keycloak/pull/302 with first
> version of Authentication SPI. Some key features:
> - Authentication SPI is used for validation of username+password and
> also for password updates. So all existing components like
> AuthenticationManager and AccountService are now calling Authentication
> SPI instead of directly calling realm.validatePassword or
> realm.updateCredentials.
>
> - Currently used just for username+password authentication. TOTP is
> still using RealmModel directly.
>
> - I've added 3 implementations of Authentication SPI.
> -- Model - This just delegates to realm.validatePassword and
> realm.updatePassword, so it's defacto the same stuff what we have now.
> This is the default implementation, which is used if no others are
> configured
> -- ExternalModel -- This delegates authentication to "external" realm.
> In other words, user will be able to authenticate in RealmA with
> credentials from RealmB.
> -- Picketlink -- This delegates authentication to Picketlink
> IdentityManager. I've added another abstraction
> PartitionManagerProvider, so it's possible to obtain Picketlink base
> class PartitionManager from various sources (for example from Picketlink
> subsystem). Default and only implementation of PartitionManagerProvider
> is initializing Picketlink with Ldap Identity store. Configuration of
> Ldap server is obtained from realm.
>
> - Propagation of identities: If user authenticated with Authentication
> SPI doesn't yet exists in realm, he will be "synced" and automatically
> created into realm. So for example if you configure Picketlink
> AuthenticationProvider and corporate LDAP with 5k users and then you
> authenticate with your corporate username/password, your user account is
> automatically created in realm and also all basic attributes (firstName,
> lastName, email) are retrieved from LDAP server, or from external-realm
> or whatever other authentication provider provides.
>
> - For update password, it's possible to configure that password will be
> updated just in some authentication providers. So for example, you can
> have read-only LDAP, which is used just for authentication users, but
> they can't update password here. Instead password might be updated just
> in "model" based Authentication Provider and synced into Keycloak DB, so
> next time user is able to authenticate with this changed password from
> Keycloak DB instead of the Ldap password.
>
> - Configuration looks like this:
>
> "authenticationProviders": [
>       {
>           "providerName": "model",
>       "passwordUpdateSupported": true
>       },
>       {
>           "providerName": "externalModel",
>           "passwordUpdateSupported": false,
>           "config": {
>               "externalRealmId": "trustedRealm"
>           }
>       },
>       {
>           "providerName": "picketlink",
>           "passwordUpdateSupported": true
>       }
> ],
>
>
> Picketlink provider doesn't have any configuration as it's currently
> automatically configured with LDAP server, which is configured for realm
> like this:
>
> "ldapServer": {
>       "connectionUrl": "ldap://localhost:10389",
>       "baseDn": "dc=keycloak,dc=org",
>       "userDnSuffix": "ou=People,dc=keycloak,dc=org",
>       "bindDn": "uid=admin,ou=system",
>       "bindCredential": "secret"
> },
>
> LDAP configuration is in separate "ldapServer" element as same LDAP
> config (and same PartitionManager) will be used for Authentication SPI
> and in the future for other things (like Sync SPI)
>
>
> - Before this, we had just KeycloakSessionFactory as only
> application-scoped component. But with adding Authentication SPI and
> Picketlink+LDAP support, we may need more components (for example IDM
> PartitionManager, which is intended to be application-scoped component).
> Hence I've introduced KeycloakRegistry, which is simple Map of
> application-scoped components. And it's attribute ServletContext instead
> of KeycloakSessionFactory. Currently this registry contains just
> KeycloakSessionFactory and PartitionManagerRegistry (in case that LDAP
> is used). It's quite simple, but sufficient for current needs...
>
> - For LDAP testing, I've reused some stuff from Picketlink+Picketbox and
> added embedded ApacheDS server into unit tests and testsuite.
>
> - If you're ok with everything and merge this, I can follow with adding
> support for configuration Authentication providers and LDAP into admin
> console (right now it's possible just through JSON). And then possibly
> Sync SPI for the batch syncing of stuff from/to Sync providers (like
> LDAP server) or other Beta1 priorities from the wishlist :)
>
> Cheers,
> Marek
>
> On 14.3.2014 16:31, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 14 March, 2014 3:21:08 PM
>>> Subject: Re: [keycloak-dev] LDAP integration
>>>
>>>
>>>
>>> On 3/14/2014 11:15 AM, Stian Thorgersen wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, 14 March, 2014 2:12:20 PM
>>>>> Subject: Re: [keycloak-dev] LDAP integration
>>>>>
>>>>> Don't we need to have LDAP as a user store?  Won't companies have a user
>>>>> LDAP store they want to point Keycloak to?  If you have an Auth SPI
>>>>> only, then you'll still need to register the users with Keycloak.
>>>> The idea with the authentication would be similar to social login. On first
>>>> login a user would be created internally in Keycloak, and there would be a
>>>> link to the user in LDAP. It would provide us with something relatively
>>>> simple without the fuzz. Social login requires registration to be enabled
>>>> for new users, but that shouldn't be required to create users that "links"
>>>> to an LDAP store.
>>>>
>>>> We can even investigate allowing multiple authentication providers for a
>>>> single realm. For example if a user exist in Keycloak you can check if
>>>> there is a LDAP link, if there is authenticate with LDAP, otherwise with
>>>> Keycloak. If no user exist, check with the other configured authentication
>>>> providers if one exists.
>>>>
>>>> In the second round we can worry about syncing, or alternatively by using
>>>> LDAP directly for users/role-mappings. I'm not 100% convinced, but I
>>>> believe the syncing approach is the simpler and probably better solution
>>>> to "federation".
>>>>
>>> So, all user updates (password, attributes, otp, etc...) will be stored
>>> in Keycloak and then synced with LDAP?
>> Can be yes, the Sync SPI needs to be flexible enough to specify what should be synced. It may also only be a one-way sync. Some examples:
>>
>> * Full sync with LDAP - if a user is added/changed in Keycloak it will be updated in LDAP, same other way around. This includes everything we can sensibly store in LDAP. It will also sync role mappings.
>> * Read only sync with LDAP - for whatever reason the admin doesn't want to let Keycloak write back to the LDAP server. In this case we'd read changes from LDAP, but not write changes back.
>> * Write only of users - for example if an application wants to have user profiles (excluding passwords, otp, etc.) in a relational database that can be queried directly by the application. This can be done by implementing the Sync SPI, and they can obviously change the way a user is represented by transforming it during the sync.
>>
>> This is most likely a stupid idea, but could we use the same syncing solution to sync between a cache and the db?!?
>>
>>> Bill
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From mposolda at redhat.com  Tue Mar 25 12:55:37 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 25 Mar 2014 17:55:37 +0100
Subject: [keycloak-dev] LDAP integration
In-Reply-To: <5331A7AC.8020102@redhat.com>
References: <1431044323.27492398.1394802758038.JavaMail.zimbra@redhat.com>	<53230E44.7080406@redhat.com>	<371746902.27615647.1394810126389.JavaMail.zimbra@redhat.com>	<53231E64.8000400@redhat.com>	<1619464837.27627350.1394811107845.JavaMail.zimbra@redhat.com>	<5330BDCC.2010405@redhat.com>
	<5331A7AC.8020102@redhat.com>
Message-ID: <5331B509.1020805@redhat.com>

Ouch... Is it with latest master including this commit 
https://github.com/keycloak/keycloak/commit/ab02dea902e51c57f321ace3290ac0f6f6b3c4bd 
?
Any stacktrace?

Marek

On 25.3.2014 16:58, Bill Burke wrote:
> Getting build failures in JPA for LDAP test
>
> On 3/24/2014 7:20 PM, Marek Posolda wrote:
>> Hi,
>>
>> I've sent PR https://github.com/keycloak/keycloak/pull/302 with first
>> version of Authentication SPI. Some key features:
>> - Authentication SPI is used for validation of username+password and
>> also for password updates. So all existing components like
>> AuthenticationManager and AccountService are now calling Authentication
>> SPI instead of directly calling realm.validatePassword or
>> realm.updateCredentials.
>>
>> - Currently used just for username+password authentication. TOTP is
>> still using RealmModel directly.
>>
>> - I've added 3 implementations of Authentication SPI.
>> -- Model - This just delegates to realm.validatePassword and
>> realm.updatePassword, so it's defacto the same stuff what we have now.
>> This is the default implementation, which is used if no others are
>> configured
>> -- ExternalModel -- This delegates authentication to "external" realm.
>> In other words, user will be able to authenticate in RealmA with
>> credentials from RealmB.
>> -- Picketlink -- This delegates authentication to Picketlink
>> IdentityManager. I've added another abstraction
>> PartitionManagerProvider, so it's possible to obtain Picketlink base
>> class PartitionManager from various sources (for example from Picketlink
>> subsystem). Default and only implementation of PartitionManagerProvider
>> is initializing Picketlink with Ldap Identity store. Configuration of
>> Ldap server is obtained from realm.
>>
>> - Propagation of identities: If user authenticated with Authentication
>> SPI doesn't yet exists in realm, he will be "synced" and automatically
>> created into realm. So for example if you configure Picketlink
>> AuthenticationProvider and corporate LDAP with 5k users and then you
>> authenticate with your corporate username/password, your user account is
>> automatically created in realm and also all basic attributes (firstName,
>> lastName, email) are retrieved from LDAP server, or from external-realm
>> or whatever other authentication provider provides.
>>
>> - For update password, it's possible to configure that password will be
>> updated just in some authentication providers. So for example, you can
>> have read-only LDAP, which is used just for authentication users, but
>> they can't update password here. Instead password might be updated just
>> in "model" based Authentication Provider and synced into Keycloak DB, so
>> next time user is able to authenticate with this changed password from
>> Keycloak DB instead of the Ldap password.
>>
>> - Configuration looks like this:
>>
>> "authenticationProviders": [
>>        {
>>            "providerName": "model",
>>        "passwordUpdateSupported": true
>>        },
>>        {
>>            "providerName": "externalModel",
>>            "passwordUpdateSupported": false,
>>            "config": {
>>                "externalRealmId": "trustedRealm"
>>            }
>>        },
>>        {
>>            "providerName": "picketlink",
>>            "passwordUpdateSupported": true
>>        }
>> ],
>>
>>
>> Picketlink provider doesn't have any configuration as it's currently
>> automatically configured with LDAP server, which is configured for realm
>> like this:
>>
>> "ldapServer": {
>>        "connectionUrl": "ldap://localhost:10389",
>>        "baseDn": "dc=keycloak,dc=org",
>>        "userDnSuffix": "ou=People,dc=keycloak,dc=org",
>>        "bindDn": "uid=admin,ou=system",
>>        "bindCredential": "secret"
>> },
>>
>> LDAP configuration is in separate "ldapServer" element as same LDAP
>> config (and same PartitionManager) will be used for Authentication SPI
>> and in the future for other things (like Sync SPI)
>>
>>
>> - Before this, we had just KeycloakSessionFactory as only
>> application-scoped component. But with adding Authentication SPI and
>> Picketlink+LDAP support, we may need more components (for example IDM
>> PartitionManager, which is intended to be application-scoped component).
>> Hence I've introduced KeycloakRegistry, which is simple Map of
>> application-scoped components. And it's attribute ServletContext instead
>> of KeycloakSessionFactory. Currently this registry contains just
>> KeycloakSessionFactory and PartitionManagerRegistry (in case that LDAP
>> is used). It's quite simple, but sufficient for current needs...
>>
>> - For LDAP testing, I've reused some stuff from Picketlink+Picketbox and
>> added embedded ApacheDS server into unit tests and testsuite.
>>
>> - If you're ok with everything and merge this, I can follow with adding
>> support for configuration Authentication providers and LDAP into admin
>> console (right now it's possible just through JSON). And then possibly
>> Sync SPI for the batch syncing of stuff from/to Sync providers (like
>> LDAP server) or other Beta1 priorities from the wishlist :)
>>
>> Cheers,
>> Marek
>>
>> On 14.3.2014 16:31, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 14 March, 2014 3:21:08 PM
>>>> Subject: Re: [keycloak-dev] LDAP integration
>>>>
>>>>
>>>>
>>>> On 3/14/2014 11:15 AM, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, 14 March, 2014 2:12:20 PM
>>>>>> Subject: Re: [keycloak-dev] LDAP integration
>>>>>>
>>>>>> Don't we need to have LDAP as a user store?  Won't companies have a user
>>>>>> LDAP store they want to point Keycloak to?  If you have an Auth SPI
>>>>>> only, then you'll still need to register the users with Keycloak.
>>>>> The idea with the authentication would be similar to social login. On first
>>>>> login a user would be created internally in Keycloak, and there would be a
>>>>> link to the user in LDAP. It would provide us with something relatively
>>>>> simple without the fuzz. Social login requires registration to be enabled
>>>>> for new users, but that shouldn't be required to create users that "links"
>>>>> to an LDAP store.
>>>>>
>>>>> We can even investigate allowing multiple authentication providers for a
>>>>> single realm. For example if a user exist in Keycloak you can check if
>>>>> there is a LDAP link, if there is authenticate with LDAP, otherwise with
>>>>> Keycloak. If no user exist, check with the other configured authentication
>>>>> providers if one exists.
>>>>>
>>>>> In the second round we can worry about syncing, or alternatively by using
>>>>> LDAP directly for users/role-mappings. I'm not 100% convinced, but I
>>>>> believe the syncing approach is the simpler and probably better solution
>>>>> to "federation".
>>>>>
>>>> So, all user updates (password, attributes, otp, etc...) will be stored
>>>> in Keycloak and then synced with LDAP?
>>> Can be yes, the Sync SPI needs to be flexible enough to specify what should be synced. It may also only be a one-way sync. Some examples:
>>>
>>> * Full sync with LDAP - if a user is added/changed in Keycloak it will be updated in LDAP, same other way around. This includes everything we can sensibly store in LDAP. It will also sync role mappings.
>>> * Read only sync with LDAP - for whatever reason the admin doesn't want to let Keycloak write back to the LDAP server. In this case we'd read changes from LDAP, but not write changes back.
>>> * Write only of users - for example if an application wants to have user profiles (excluding passwords, otp, etc.) in a relational database that can be queried directly by the application. This can be done by implementing the Sync SPI, and they can obviously change the way a user is represented by transforming it during the sync.
>>>
>>> This is most likely a stupid idea, but could we use the same syncing solution to sync between a cache and the db?!?
>>>
>>>> Bill
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Wed Mar 26 09:26:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Mar 2014 09:26:24 -0400
Subject: [keycloak-dev] LDAP test still failing
Message-ID: <5332D580.6040206@redhat.com>

java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
         at org.junit.Assert.fail(Assert.java:88)
         at org.junit.Assert.failNotEquals(Assert.java:743)
         at org.junit.Assert.assertEquals(Assert.java:118)
         at org.junit.Assert.assertEquals(Assert.java:144)
         at 
org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)

Can you please fix it?  Otherwise I'm just going to comment it out.

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

From bburke at redhat.com  Wed Mar 26 09:45:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 26 Mar 2014 09:45:01 -0400
Subject: [keycloak-dev] LDAP test still failing
In-Reply-To: <5332D580.6040206@redhat.com>
References: <5332D580.6040206@redhat.com>
Message-ID: <5332D9DD.9020506@redhat.com>

Still failing after your latest commit.

On 3/26/2014 9:26 AM, Bill Burke wrote:
> java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
>           at org.junit.Assert.fail(Assert.java:88)
>           at org.junit.Assert.failNotEquals(Assert.java:743)
>           at org.junit.Assert.assertEquals(Assert.java:118)
>           at org.junit.Assert.assertEquals(Assert.java:144)
>           at
> org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)
>
> Can you please fix it?  Otherwise I'm just going to comment it out.
>

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

From stian at redhat.com  Wed Mar 26 10:21:07 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 26 Mar 2014 10:21:07 -0400 (EDT)
Subject: [keycloak-dev] LDAP test still failing
In-Reply-To: <5332D9DD.9020506@redhat.com>
References: <5332D580.6040206@redhat.com> <5332D9DD.9020506@redhat.com>
Message-ID: <860458878.1369074.1395843667112.JavaMail.zimbra@redhat.com>

Master works for me now. Is this still failing for you?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 26 March, 2014 1:45:01 PM
> Subject: Re: [keycloak-dev] LDAP test still failing
> 
> Still failing after your latest commit.
> 
> On 3/26/2014 9:26 AM, Bill Burke wrote:
> > java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
> >           at org.junit.Assert.fail(Assert.java:88)
> >           at org.junit.Assert.failNotEquals(Assert.java:743)
> >           at org.junit.Assert.assertEquals(Assert.java:118)
> >           at org.junit.Assert.assertEquals(Assert.java:144)
> >           at
> > org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)
> >
> > Can you please fix it?  Otherwise I'm just going to comment it out.
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Wed Mar 26 10:21:40 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 26 Mar 2014 15:21:40 +0100
Subject: [keycloak-dev] LDAP test still failing
In-Reply-To: <5332D9DD.9020506@redhat.com>
References: <5332D580.6040206@redhat.com> <5332D9DD.9020506@redhat.com>
Message-ID: <5332E274.2080508@redhat.com>

Sorry for troubles, however I am not able to reproduce and CI is passing 
too:-\

Are you on windows? Would be helpful if you can you send me output of:
cd model/jpa
mvn test -Dtest=AuthProvidersLDAPTest

Thanks,
Marek

On 26.3.2014 14:45, Bill Burke wrote:
> Still failing after your latest commit.
>
> On 3/26/2014 9:26 AM, Bill Burke wrote:
>> java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
>>            at org.junit.Assert.fail(Assert.java:88)
>>            at org.junit.Assert.failNotEquals(Assert.java:743)
>>            at org.junit.Assert.assertEquals(Assert.java:118)
>>            at org.junit.Assert.assertEquals(Assert.java:144)
>>            at
>> org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)
>>
>> Can you please fix it?  Otherwise I'm just going to comment it out.
>>


From vrockai at redhat.com  Wed Mar 26 11:34:53 2014
From: vrockai at redhat.com (Viliam Rockai)
Date: Wed, 26 Mar 2014 16:34:53 +0100
Subject: [keycloak-dev] LDAP test still failing
In-Reply-To: <5332E274.2080508@redhat.com>
References: <5332D580.6040206@redhat.com> <5332D9DD.9020506@redhat.com>
	<5332E274.2080508@redhat.com>
Message-ID: <1395848093.1696.1.camel@vrockai-laptop>

Hey Marek,

I've tried the current KC master on my Win machine, and I've got the
error, too. I'm attaching the output of my windows cmd.

Viliam

On Wed, 2014-03-26 at 15:21 +0100, Marek Posolda wrote:
> Sorry for troubles, however I am not able to reproduce and CI is passing 
> too:-\
> 
> Are you on windows? Would be helpful if you can you send me output of:
> cd model/jpa
> mvn test -Dtest=AuthProvidersLDAPTest
> 
> Thanks,
> Marek
> 
> On 26.3.2014 14:45, Bill Burke wrote:
> > Still failing after your latest commit.
> >
> > On 3/26/2014 9:26 AM, Bill Burke wrote:
> >> java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
> >>            at org.junit.Assert.fail(Assert.java:88)
> >>            at org.junit.Assert.failNotEquals(Assert.java:743)
> >>            at org.junit.Assert.assertEquals(Assert.java:118)
> >>            at org.junit.Assert.assertEquals(Assert.java:144)
> >>            at
> >> org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)
> >>
> >> Can you please fix it?  Otherwise I'm just going to comment it out.
> >>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kc.out.zip
Type: application/zip
Size: 18291 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140326/5fca60ed/attachment-0001.zip 

From mposolda at redhat.com  Wed Mar 26 12:50:31 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 26 Mar 2014 17:50:31 +0100
Subject: [keycloak-dev] LDAP test still failing
In-Reply-To: <1395848093.1696.1.camel@vrockai-laptop>
References: <5332D580.6040206@redhat.com> <5332D9DD.9020506@redhat.com>	
	<5332E274.2080508@redhat.com>
	<1395848093.1696.1.camel@vrockai-laptop>
Message-ID: <53330557.2060502@redhat.com>

Thanks! I will try to find and setup some windows environment where I 
can reproduce and will try to fix it.

Marek

On 26.3.2014 16:34, Viliam Rockai wrote:
> Hey Marek,
>
> I've tried the current KC master on my Win machine, and I've got the
> error, too. I'm attaching the output of my windows cmd.
>
> Viliam
>
> On Wed, 2014-03-26 at 15:21 +0100, Marek Posolda wrote:
>> Sorry for troubles, however I am not able to reproduce and CI is passing
>> too:-\
>>
>> Are you on windows? Would be helpful if you can you send me output of:
>> cd model/jpa
>> mvn test -Dtest=AuthProvidersLDAPTest
>>
>> Thanks,
>> Marek
>>
>> On 26.3.2014 14:45, Bill Burke wrote:
>>> Still failing after your latest commit.
>>>
>>> On 3/26/2014 9:26 AM, Bill Burke wrote:
>>>> java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
>>>>             at org.junit.Assert.fail(Assert.java:88)
>>>>             at org.junit.Assert.failNotEquals(Assert.java:743)
>>>>             at org.junit.Assert.assertEquals(Assert.java:118)
>>>>             at org.junit.Assert.assertEquals(Assert.java:144)
>>>>             at
>>>> org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)
>>>>
>>>> Can you please fix it?  Otherwise I'm just going to comment it out.
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Thu Mar 27 11:39:02 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 27 Mar 2014 16:39:02 +0100
Subject: [keycloak-dev] LDAP test still failing
In-Reply-To: <53330557.2060502@redhat.com>
References: <5332D580.6040206@redhat.com>
	<5332D9DD.9020506@redhat.com>		<5332E274.2080508@redhat.com>	<1395848093.1696.1.camel@vrockai-laptop>
	<53330557.2060502@redhat.com>
Message-ID: <53344616.5090504@redhat.com>

I reproduced the issue on Windows and sent PR 
https://github.com/keycloak/keycloak/pull/308 , which is passing for me 
on windows. Hope it will fix the issue for you too.

Marek

On 26.3.2014 17:50, Marek Posolda wrote:
> Thanks! I will try to find and setup some windows environment where I
> can reproduce and will try to fix it.
>
> Marek
>
> On 26.3.2014 16:34, Viliam Rockai wrote:
>> Hey Marek,
>>
>> I've tried the current KC master on my Win machine, and I've got the
>> error, too. I'm attaching the output of my windows cmd.
>>
>> Viliam
>>
>> On Wed, 2014-03-26 at 15:21 +0100, Marek Posolda wrote:
>>> Sorry for troubles, however I am not able to reproduce and CI is passing
>>> too:-\
>>>
>>> Are you on windows? Would be helpful if you can you send me output of:
>>> cd model/jpa
>>> mvn test -Dtest=AuthProvidersLDAPTest
>>>
>>> Thanks,
>>> Marek
>>>
>>> On 26.3.2014 14:45, Bill Burke wrote:
>>>> Still failing after your latest commit.
>>>>
>>>> On 3/26/2014 9:26 AM, Bill Burke wrote:
>>>>> java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
>>>>>              at org.junit.Assert.fail(Assert.java:88)
>>>>>              at org.junit.Assert.failNotEquals(Assert.java:743)
>>>>>              at org.junit.Assert.assertEquals(Assert.java:118)
>>>>>              at org.junit.Assert.assertEquals(Assert.java:144)
>>>>>              at
>>>>> org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)
>>>>>
>>>>> Can you please fix it?  Otherwise I'm just going to comment it out.
>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Mar 27 12:36:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 27 Mar 2014 12:36:02 -0400
Subject: [keycloak-dev] logout for keycloak.js
Message-ID: <53345372.1060401@redhat.com>

This may be useful:

http://openid.net/specs/openid-connect-session-1_0.html


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

From stian at redhat.com  Thu Mar 27 12:53:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 27 Mar 2014 12:53:50 -0400 (EDT)
Subject: [keycloak-dev] logout for keycloak.js
In-Reply-To: <53345372.1060401@redhat.com>
References: <53345372.1060401@redhat.com>
Message-ID: <521039503.3033939.1395939230003.JavaMail.zimbra@redhat.com>

Single-Sign Out is also an issue with other types of "public" clients such a mobile apps, and oauth clients.

I'll have a look once I get the first round of audit work completed.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 27 March, 2014 4:36:02 PM
> Subject: [keycloak-dev] logout for keycloak.js
> 
> This may be useful:
> 
> http://openid.net/specs/openid-connect-session-1_0.html
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Mar 27 13:01:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 27 Mar 2014 13:01:22 -0400
Subject: [keycloak-dev] logout for keycloak.js
In-Reply-To: <521039503.3033939.1395939230003.JavaMail.zimbra@redhat.com>
References: <53345372.1060401@redhat.com>
	<521039503.3033939.1395939230003.JavaMail.zimbra@redhat.com>
Message-ID: <53345962.4000302@redhat.com>

It is mitigated somewhat as when a logout happens I set a 
UserModel.notBefore setting.  So refresh tokens will be invalidated. 
But there is a window between when the logout occurs and when the access 
token expires.

On 3/27/2014 12:53 PM, Stian Thorgersen wrote:
> Single-Sign Out is also an issue with other types of "public" clients such a mobile apps, and oauth clients.
>
> I'll have a look once I get the first round of audit work completed.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 27 March, 2014 4:36:02 PM
>> Subject: [keycloak-dev] logout for keycloak.js
>>
>> This may be useful:
>>
>> http://openid.net/specs/openid-connect-session-1_0.html
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Thu Mar 27 13:05:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 27 Mar 2014 13:05:05 -0400
Subject: [keycloak-dev] threat model
Message-ID: <53345A41.5050909@redhat.com>

Great doc I finally found:

http://tools.ietf.org/html/rfc6819

After browsing it, I still can't find pros/cons of public vs. 
confidential clients.  Especially when we perform all the other 
validations suggested.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Mar 27 13:17:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 27 Mar 2014 13:17:18 -0400
Subject: [keycloak-dev] threat model
In-Reply-To: <53345A41.5050909@redhat.com>
References: <53345A41.5050909@redhat.com>
Message-ID: <53345D1E.9010404@redhat.com>

There is some good stuff in this document though that we need to 
implement specifically clickjacking:

http://tools.ietf.org/html/rfc6819#page-33

On 3/27/2014 1:05 PM, Bill Burke wrote:
> Great doc I finally found:
>
> http://tools.ietf.org/html/rfc6819
>
> After browsing it, I still can't find pros/cons of public vs.
> confidential clients.  Especially when we perform all the other
> validations suggested.
>

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

From bburke at redhat.com  Thu Mar 27 14:21:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 27 Mar 2014 14:21:43 -0400
Subject: [keycloak-dev] LDAP test still failing
In-Reply-To: <53344616.5090504@redhat.com>
References: <5332D580.6040206@redhat.com>	<5332D9DD.9020506@redhat.com>		<5332E274.2080508@redhat.com>	<1395848093.1696.1.camel@vrockai-laptop>	<53330557.2060502@redhat.com>
	<53344616.5090504@redhat.com>
Message-ID: <53346C37.1020001@redhat.com>

Works now.  Thanks for fixing and implementing this.  This feature will 
help out on multiple levels, not just technical.

On 3/27/2014 11:39 AM, Marek Posolda wrote:
> I reproduced the issue on Windows and sent PR
> https://github.com/keycloak/keycloak/pull/308 , which is passing for me
> on windows. Hope it will fix the issue for you too.
>
> Marek
>
> On 26.3.2014 17:50, Marek Posolda wrote:
>> Thanks! I will try to find and setup some windows environment where I
>> can reproduce and will try to fix it.
>>
>> Marek
>>
>> On 26.3.2014 16:34, Viliam Rockai wrote:
>>> Hey Marek,
>>>
>>> I've tried the current KC master on my Win machine, and I've got the
>>> error, too. I'm attaching the output of my windows cmd.
>>>
>>> Viliam
>>>
>>> On Wed, 2014-03-26 at 15:21 +0100, Marek Posolda wrote:
>>>> Sorry for troubles, however I am not able to reproduce and CI is passing
>>>> too:-\
>>>>
>>>> Are you on windows? Would be helpful if you can you send me output of:
>>>> cd model/jpa
>>>> mvn test -Dtest=AuthProvidersLDAPTest
>>>>
>>>> Thanks,
>>>> Marek
>>>>
>>>> On 26.3.2014 14:45, Bill Burke wrote:
>>>>> Still failing after your latest commit.
>>>>>
>>>>> On 3/26/2014 9:26 AM, Bill Burke wrote:
>>>>>> java.lang.AssertionError: expected:<SUCCESS> but was:<INVALID_CREDENTIALS>
>>>>>>               at org.junit.Assert.fail(Assert.java:88)
>>>>>>               at org.junit.Assert.failNotEquals(Assert.java:743)
>>>>>>               at org.junit.Assert.assertEquals(Assert.java:118)
>>>>>>               at org.junit.Assert.assertEquals(Assert.java:144)
>>>>>>               at
>>>>>> org.keycloak.model.test.AuthProvidersLDAPTest.testLdapAuthentication(AuthProvidersLDAPTest.java:86)
>>>>>>
>>>>>> Can you please fix it?  Otherwise I'm just going to comment it out.
>>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From adrian.mitev at gmail.com  Fri Mar 28 06:58:08 2014
From: adrian.mitev at gmail.com (Adrian Mitev)
Date: Fri, 28 Mar 2014 12:58:08 +0200
Subject: [keycloak-dev] Features whishlist
In-Reply-To: <CAN_QJsHtXoBG1-jk8AJ0BAUYH3JVbN23j=+2y=7xV=eDKc76fw@mail.gmail.com>
References: <CAN_QJsEbBL1X7nGeFxARFchqus67uQ51FBF9pnXNJBhVuSNthg@mail.gmail.com>
	<532AEB83.80608@redhat.com>
	<CAN_QJsHtXoBG1-jk8AJ0BAUYH3JVbN23j=+2y=7xV=eDKc76fw@mail.gmail.com>
Message-ID: <CAN_QJsEbkyanVssZ4FNpUz+-u=O4iu5pZhTDcF5Rr-gmi8b_Fw@mail.gmail.com>

Should I add these in JIRA as feature requests?

On Thu, Mar 20, 2014 at 3:47 PM, Adrian Mitev <adrian.mitev at gmail.com>wrote:

>
>
>
> On Thu, Mar 20, 2014 at 3:22 PM, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 3/20/2014 6:47 AM, Adrian Mitev wrote:
>> > Hi guys! I'm very interested in Keycloak and would like to share with
>> > you some ideas that come from user requirements I currently have or had
>> > in the past that you may find useful to add in Keycloak.
>> > * Automatically revoke access to user account after a (configurable)
>> > number of invalid sign-on passwords until the system administrator has
>> > unlocked the account or automatically after an administrator-defined
>> > interval - I know that with such feature an attacker could lock user
>> > accounts by simply knowing usernames/emails. However I have a case of an
>> > Intranet application that is accessible only inside the company and
>> > could trace such attackers by their ip addresses.
>>
>> Working on Brute force detection now.  First iteration will increasingly
>> add a "not before" time on successive login failures.  Second iteration
>> will include IP address options.
>>
>> > * Record and report (i.e. email sending) on failed login attempts
>> outlining
>> > * Force password changes at regular (configurable) intervals or
>> > * Automatically reset the password and send a new one to the user via
>> email
>> > * Can ensure that the new password has not been used before in a number
>> > (configurable) of password changes
>> > * Login using digital signature in a smart card or p12 file
>>
>> This something different than OTP?
>>
> A customer company has a policy that a password for user account should be
> changed every week. This counts for special type of users that access more
> sensitive information.
>
>
>>
>> > * Security questions for password recovery
>> >
>> > Other that I found as issues in other Identity Providers
>> > * Support many accounts (~10K) within a reasonable amount of time
>> > * When providing an authentication client (maven dependency) add only
>> > the needed set of dependencies. I know this sounds silly but I have
>> > experience with a client library provided by the Identity Provider that
>> > had a compile dependency to apache ant...
>> >
>>
>> So far our adapters are installed once onto the app server.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140328/6325f8c6/attachment-0001.html 

From stian at redhat.com  Fri Mar 28 07:26:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 28 Mar 2014 07:26:37 -0400 (EDT)
Subject: [keycloak-dev] Features whishlist
In-Reply-To: <CAN_QJsEbkyanVssZ4FNpUz+-u=O4iu5pZhTDcF5Rr-gmi8b_Fw@mail.gmail.com>
References: <CAN_QJsEbBL1X7nGeFxARFchqus67uQ51FBF9pnXNJBhVuSNthg@mail.gmail.com>
	<532AEB83.80608@redhat.com>
	<CAN_QJsHtXoBG1-jk8AJ0BAUYH3JVbN23j=+2y=7xV=eDKc76fw@mail.gmail.com>
	<CAN_QJsEbkyanVssZ4FNpUz+-u=O4iu5pZhTDcF5Rr-gmi8b_Fw@mail.gmail.com>
Message-ID: <247370971.3552438.1396005997617.JavaMail.zimbra@redhat.com>

Yes, please do

----- Original Message -----
> From: "Adrian Mitev" <adrian.mitev at gmail.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 28 March, 2014 10:58:08 AM
> Subject: Re: [keycloak-dev] Features whishlist
> 
> Should I add these in JIRA as feature requests?
> 
> On Thu, Mar 20, 2014 at 3:47 PM, Adrian Mitev < adrian.mitev at gmail.com >
> wrote:
> 
> 
> 
> 
> 
> 
> On Thu, Mar 20, 2014 at 3:22 PM, Bill Burke < bburke at redhat.com > wrote:
> 
> 
> 
> 
> 
> On 3/20/2014 6:47 AM, Adrian Mitev wrote:
> > Hi guys! I'm very interested in Keycloak and would like to share with
> > you some ideas that come from user requirements I currently have or had
> > in the past that you may find useful to add in Keycloak.
> > * Automatically revoke access to user account after a (configurable)
> > number of invalid sign-on passwords until the system administrator has
> > unlocked the account or automatically after an administrator-defined
> > interval - I know that with such feature an attacker could lock user
> > accounts by simply knowing usernames/emails. However I have a case of an
> > Intranet application that is accessible only inside the company and
> > could trace such attackers by their ip addresses.
> 
> Working on Brute force detection now. First iteration will increasingly
> add a "not before" time on successive login failures. Second iteration
> will include IP address options.
> 
> > * Record and report (i.e. email sending) on failed login attempts outlining
> > * Force password changes at regular (configurable) intervals or
> > * Automatically reset the password and send a new one to the user via email
> > * Can ensure that the new password has not been used before in a number
> > (configurable) of password changes
> > * Login using digital signature in a smart card or p12 file
> 
> This something different than OTP?
> A customer company has a policy that a password for user account should be
> changed every week. This counts for special type of users that access more
> sensitive information.
> 
> 
> 
> 
> 
> > * Security questions for password recovery
> > 
> > Other that I found as issues in other Identity Providers
> > * Support many accounts (~10K) within a reasonable amount of time
> > * When providing an authentication client (maven dependency) add only
> > the needed set of dependencies. I know this sounds silly but I have
> > experience with a client library provided by the Identity Provider that
> > had a compile dependency to apache ant...
> > 
> 
> So far our adapters are installed once onto the app server.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Fri Mar 28 09:33:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 28 Mar 2014 09:33:47 -0400 (EDT)
Subject: [keycloak-dev] Idea for brute force protection
In-Reply-To: <53381317.3639039.1396013158373.JavaMail.zimbra@redhat.com>
Message-ID: <480850267.3645419.1396013627514.JavaMail.zimbra@redhat.com>

While working on audit an idea popped into my head. What about if after N failed attempts we disable the users account, then send an email to the user saying something like:

------------

We have recently detected a number of failed login attempts to your account:

  * 28/03/2014 14:27 from 80.129.51.201
  * 28/03/2014 14:26 from 80.129.51.201
  * 28/03/2014 14:25 from 80.129.51.201
  * 28/03/2014 14:24 from 80.129.51.201

To prevent unauthorized access to your account it has been disabled. To enable your account click on the following link (or contact an admin):

http://localhost:8080/auth/rest/realms/tokens/auth/request/login-actions/verify-account?key=a3240r9je908rjgf3984jncs9d8ajvc9834hf983434tf34t34

------------

We could have a drop-down under realm settings to select the 'brute force' protection policy, from one of:

* Sleep - sleep for N seconds on login (increased for each attempt)
* Temporary disable - disable login for the account until some time in the future (may also send an email to user to indicate this)
* User can re-enable - the proposal from above
* Admin can re-enable - similar to above, but the email is sent to an admin instead of the user



From bburke at redhat.com  Fri Mar 28 11:56:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Mar 2014 11:56:02 -0400
Subject: [keycloak-dev] Idea for brute force protection
In-Reply-To: <480850267.3645419.1396013627514.JavaMail.zimbra@redhat.com>
References: <480850267.3645419.1396013627514.JavaMail.zimbra@redhat.com>
Message-ID: <53359B92.1050708@redhat.com>

Ok.  I'm working on something now that does most of this minus the 
email.  Have had Resteasy work this week too though.

On 3/28/2014 9:33 AM, Stian Thorgersen wrote:
> While working on audit an idea popped into my head. What about if after N failed attempts we disable the users account, then send an email to the user saying something like:
>
> ------------
>
> We have recently detected a number of failed login attempts to your account:
>
>    * 28/03/2014 14:27 from 80.129.51.201
>    * 28/03/2014 14:26 from 80.129.51.201
>    * 28/03/2014 14:25 from 80.129.51.201
>    * 28/03/2014 14:24 from 80.129.51.201
>
> To prevent unauthorized access to your account it has been disabled. To enable your account click on the following link (or contact an admin):
>
> http://localhost:8080/auth/rest/realms/tokens/auth/request/login-actions/verify-account?key=a3240r9je908rjgf3984jncs9d8ajvc9834hf983434tf34t34
>
> ------------
>
> We could have a drop-down under realm settings to select the 'brute force' protection policy, from one of:
>
> * Sleep - sleep for N seconds on login (increased for each attempt)
> * Temporary disable - disable login for the account until some time in the future (may also send an email to user to indicate this)
> * User can re-enable - the proposal from above
> * Admin can re-enable - similar to above, but the email is sent to an admin instead of the user
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Fri Mar 28 12:05:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Mar 2014 12:05:49 -0400
Subject: [keycloak-dev] Do we need a RDMS/Mongo backed Audit Log?
Message-ID: <53359DDD.8080307@redhat.com>

If you look at things like fail2ban, they parse logs in order to make 
decisions.

Do we really need our Audit Log to be backed by an actual database? 
Yes, we need an "Event" or "Action" log that a user and/or admin sees of 
things they need to be aware of.  But logging of successful logins, 
login failures, and the like should be pushed to a rolling log file, no? 
  Then Keycloak could hook into things like fail2ban.

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

From stian at redhat.com  Fri Mar 28 13:19:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 28 Mar 2014 13:19:50 -0400 (EDT)
Subject: [keycloak-dev] Do we need a RDMS/Mongo backed Audit Log?
In-Reply-To: <53359DDD.8080307@redhat.com>
References: <53359DDD.8080307@redhat.com>
Message-ID: <79093110.3813833.1396027190843.JavaMail.zimbra@redhat.com>

The way I'm currently implementing it is that there's two interfaces:

* AuditListener
* AuditProvider

An AuditListener listenes for audit events, but doesn't provide a way to read them. So far I've added an implementation using jboss-logging for this.

An AuditProvider listens for audit events, but also provides a way to query for events. This is used by the admin console and the account management to view audit events. I haven't done any implementations of this yet.

The idea was that a realm could have one or more listeners, but only a single provider.

Main issue with parsing rolling files would be to find events associated with particular users, or applications. Not sure we need to support finding events by-app, but we certainly need to be able to display events for a specific user.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 28 March, 2014 4:05:49 PM
> Subject: [keycloak-dev] Do we need a RDMS/Mongo backed Audit Log?
> 
> If you look at things like fail2ban, they parse logs in order to make
> decisions.
> 
> Do we really need our Audit Log to be backed by an actual database?
> Yes, we need an "Event" or "Action" log that a user and/or admin sees of
> things they need to be aware of.  But logging of successful logins,
> login failures, and the like should be pushed to a rolling log file, no?
>   Then Keycloak could hook into things like fail2ban.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From Anil.Saldhana at redhat.com  Fri Mar 28 13:30:22 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 28 Mar 2014 12:30:22 -0500
Subject: [keycloak-dev] Discussion on OAuth and Enterprise Federation
In-Reply-To: <5335B17F.1050405@redhat.com>
References: <5335B17F.1050405@redhat.com>
Message-ID: <5335B1AE.3050002@redhat.com>




-------- Original Message --------
Subject: 	[security-dev] Discussion on OAuth and Enterprise Federation
Date: 	Fri, 28 Mar 2014 12:29:35 -0500
From: 	Anil Saldhana <Anil.Saldhana at redhat.com>
To: 	security-dev at lists.jboss.org <security-dev at lists.jboss.org>



There is an interesting thread on the IETF OAuth mailing list.
http://www.ietf.org/mail-archive/web/oauth/current/msg12552.html

FYI.
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140328/4fa212fa/attachment.html 

From ssilvert at redhat.com  Fri Mar 28 15:02:59 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 28 Mar 2014 15:02:59 -0400
Subject: [keycloak-dev] versioning of js packages
Message-ID: <5335C763.50106@redhat.com>

I just noticed that we have js libs like angular checked into GitHub:
https://github.com/keycloak/keycloak/tree/master/admin-ui/src/main/resources/META-INF/resources/admin/lib/angular

As far as I can tell, this requires manually uploading new versions 
whenever you want to upgrade.

Have you guys tried or considered the npm Maven plugin?
http://java.dzone.com/articles/introducing-npm-maven-plugin

Any thoughts about js package management in a Maven project?

Stan

From lukas at fryc.eu  Mon Mar 31 07:43:02 2014
From: lukas at fryc.eu (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Mon, 31 Mar 2014 13:43:02 +0200
Subject: [keycloak-dev] versioning of js packages
In-Reply-To: <5335C763.50106@redhat.com>
References: <5335C763.50106@redhat.com>
Message-ID: <CAEroY35CbvK9SG3HOMLbej-HE=dGcxA5rMRtv0S3KEQBXwfb5w@mail.gmail.com>

Hey Stan,

I would recommend Bower  [1] for managing browser deps (together with Grunt
for compilation steps / NPM for managing build dependencies).

You can use Bower either

1) powered by Grunt (https://github.com/eirslett/frontend-maven-plugin)
2) or standalone (certainly there are plugins to use Bower standalone
https://bitbucket.org/cofarrell/bower-maven-plugin, but not in central?)

Usually you use Grunt to compile and copy resources around, it's much more
straight-forward than in Maven. ;-)

I can put together an initial setup if you agree.

~ Lukas


[1] http://bower.io/


On Fri, Mar 28, 2014 at 8:02 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> I just noticed that we have js libs like angular checked into GitHub:
>
> https://github.com/keycloak/keycloak/tree/master/admin-ui/src/main/resources/META-INF/resources/admin/lib/angular
>
> As far as I can tell, this requires manually uploading new versions
> whenever you want to upgrade.
>
> Have you guys tried or considered the npm Maven plugin?
> http://java.dzone.com/articles/introducing-npm-maven-plugin
>
> Any thoughts about js package management in a Maven project?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140331/3ca43dec/attachment-0001.html 

From stian at redhat.com  Mon Mar 31 08:08:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 31 Mar 2014 08:08:42 -0400 (EDT)
Subject: [keycloak-dev] versioning of js packages
In-Reply-To: <5335C763.50106@redhat.com>
References: <5335C763.50106@redhat.com>
Message-ID: <536811077.4489853.1396267722315.JavaMail.zimbra@redhat.com>

Without any tests for the admin console, upgrading the AngularJS version is quite time consuming as everything has to be manually tested. Until that's sorted I don't see this as a big priority.

Whatever solution we choose for this have to:

* Be the same as used for AngularJS patternfly project and LiveOak console
* Be in Maven central
* Not require installing Bower, Grunt or NPM - building Keycloak should only require Java + Maven

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 28 March, 2014 7:02:59 PM
> Subject: [keycloak-dev] versioning of js packages
> 
> I just noticed that we have js libs like angular checked into GitHub:
> https://github.com/keycloak/keycloak/tree/master/admin-ui/src/main/resources/META-INF/resources/admin/lib/angular
> 
> As far as I can tell, this requires manually uploading new versions
> whenever you want to upgrade.
> 
> Have you guys tried or considered the npm Maven plugin?
> http://java.dzone.com/articles/introducing-npm-maven-plugin
> 
> Any thoughts about js package management in a Maven project?
> 
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From vrockai at redhat.com  Mon Mar 31 08:23:41 2014
From: vrockai at redhat.com (Viliam Rockai)
Date: Mon, 31 Mar 2014 14:23:41 +0200
Subject: [keycloak-dev] versioning of js packages
In-Reply-To: <536811077.4489853.1396267722315.JavaMail.zimbra@redhat.com>
References: <5335C763.50106@redhat.com>
	<536811077.4489853.1396267722315.JavaMail.zimbra@redhat.com>
Message-ID: <1396268621.10110.6.camel@vrockai-laptop>

Hey all,

We have a proposal solution already implemented in LO. We use this maven
plugin:
https://github.com/eirslett/frontend-maven-plugin

It just downloads node.js/bower/grunt and use it locally, no need to
install those on your system. 
This is how we have it in the LO right now (it'll be changed in the
future):
https://github.com/liveoak-io/liveoak/blob/master/console/pom.xml#L143

Right now, we store 3rd party JS libs in git, too, but we can update
them using bower (run from maven). I would prefer to make this part of
the build process in the future.

Viliam

On Mon, 2014-03-31 at 08:08 -0400, Stian Thorgersen wrote:
> Without any tests for the admin console, upgrading the AngularJS version is quite time consuming as everything has to be manually tested. Until that's sorted I don't see this as a big priority.
> 
> Whatever solution we choose for this have to:
> 
> * Be the same as used for AngularJS patternfly project and LiveOak console
> * Be in Maven central
> * Not require installing Bower, Grunt or NPM - building Keycloak should only require Java + Maven
> 
> ----- Original Message -----
> > From: "Stan Silvert" <ssilvert at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, 28 March, 2014 7:02:59 PM
> > Subject: [keycloak-dev] versioning of js packages
> > 
> > I just noticed that we have js libs like angular checked into GitHub:
> > https://github.com/keycloak/keycloak/tree/master/admin-ui/src/main/resources/META-INF/resources/admin/lib/angular
> > 
> > As far as I can tell, this requires manually uploading new versions
> > whenever you want to upgrade.
> > 
> > Have you guys tried or considered the npm Maven plugin?
> > http://java.dzone.com/articles/introducing-npm-maven-plugin
> > 
> > Any thoughts about js package management in a Maven project?
> > 
> > Stan
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 



From matzew at apache.org  Mon Mar 31 11:57:09 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 31 Mar 2014 17:57:09 +0200
Subject: [keycloak-dev] Keycloak WAR inside on an EAR file ?
Message-ID: <CAAg5f2RTa6EZy_qLbrK70NmoW2om2bLWkN7Zhgo7Td=P9t02jg@mail.gmail.com>

Hello,

I tried to pull the auth-server.war file into an EAR. Once that is deployed
to the JBoss 7.1.1 (I did not try WildFly), I am getting this error on the
JAX-RS Application initialization:

17:55:00,113 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]]
(MSC service thread 1-14) StandardWrapper.Throwable:
java.lang.RuntimeException: Failed to construct public
org.keycloak.server.KeycloakServerApplication(javax.servlet.ServletContext)
throws java.io.FileNotFoundException
    at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:144)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:282)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:259)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:85)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873)
[jbossweb-7.0.13.Final.jar:]
    at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90)
[jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[rt.jar:1.7.0_09]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[rt.jar:1.7.0_09]
    at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
Caused by: org.jboss.resteasy.spi.LoggableFailure: Unable to find
contextual data of type: javax.servlet.ServletContext
    at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:53)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at $Proxy39.getContextPath(Unknown Source)  at
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:37)
[keycloak-services-1.0-alpha-4.jar:]
    at org.keycloak.server.KeycloakServerApplication.<init>(KeycloakServerApplication.java:41)
[classes:]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) [rt.jar:1.7.0_09]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
[rt.jar:1.7.0_09]
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[rt.jar:1.7.0_09]
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
[rt.jar:1.7.0_09]
    at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132)
[resteasy-jaxrs-2.3.2.Final.jar:]
    ... 14 more

17:55:00,123 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]]
(MSC service thread 1-14) Servlet /auth threw load() exception:
org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data
of type: javax.servlet.ServletContext
    at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:53)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at $Proxy39.getContextPath(Unknown Source)  at
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:37)
[keycloak-services-1.0-alpha-4.jar:]
    at org.keycloak.server.KeycloakServerApplication.<init>(KeycloakServerApplication.java:41)
[classes:]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method) [rt.jar:1.7.0_09]
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
[rt.jar:1.7.0_09]
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[rt.jar:1.7.0_09]
    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
[rt.jar:1.7.0_09]
    at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:282)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:259)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:85)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
[resteasy-jaxrs-2.3.2.Final.jar:]
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655)
[jbossweb-7.0.13.Final.jar:]
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873)
[jbossweb-7.0.13.Final.jar:]
    at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90)
[jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
[rt.jar:1.7.0_09]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
[rt.jar:1.7.0_09]
    at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]

I wonder if there is anything wrong here, w/ the
jboss-deployment-structure.xml file of the actual WAR file from Keycloak?

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140331/39acdae6/attachment.html 

From matzew at apache.org  Mon Mar 31 11:57:29 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 31 Mar 2014 17:57:29 +0200
Subject: [keycloak-dev] Keycloak WAR inside on an EAR file ?
In-Reply-To: <CAAg5f2RTa6EZy_qLbrK70NmoW2om2bLWkN7Zhgo7Td=P9t02jg@mail.gmail.com>
References: <CAAg5f2RTa6EZy_qLbrK70NmoW2om2bLWkN7Zhgo7Td=P9t02jg@mail.gmail.com>
Message-ID: <CAAg5f2Qn7DDZGWQHjWc3Fhf23p7Urst2Syz0LziRiVxmjb-MTQ@mail.gmail.com>

NOTE: I am using Alpha-4 version


On Mon, Mar 31, 2014 at 5:57 PM, Matthias Wessendorf <matzew at apache.org>wrote:

> Hello,
>
> I tried to pull the auth-server.war file into an EAR. Once that is
> deployed to the JBoss 7.1.1 (I did not try WildFly), I am getting this
> error on the JAX-RS Application initialization:
>
> 17:55:00,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] (MSC service thread 1-14) StandardWrapper.Throwable: java.lang.RuntimeException: Failed to construct public org.keycloak.server.KeycloakServerApplication(javax.servlet.ServletContext) throws java.io.FileNotFoundException
>     at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:144) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:282) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:259) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:85) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.13.Final.jar:]
>     at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.13.Final.jar:]
>     at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.13.Final.jar:]
>     at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.13.Final.jar:]
>     at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> Caused by: org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data of type: javax.servlet.ServletContext
>     at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:53) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at $Proxy39.getContextPath(Unknown Source)  at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:37) [keycloak-services-1.0-alpha-4.jar:]
>     at org.keycloak.server.KeycloakServerApplication.<init>(KeycloakServerApplication.java:41) [classes:]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_09]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_09]
>     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_09]
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_09]
>     at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132) [resteasy-jaxrs-2.3.2.Final.jar:]
>     ... 14 more
>
> 17:55:00,123 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] (MSC service thread 1-14) Servlet /auth threw load() exception: org.jboss.resteasy.spi.LoggableFailure: Unable to find contextual data of type: javax.servlet.ServletContext
>     at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:53) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at $Proxy39.getContextPath(Unknown Source)  at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:37) [keycloak-services-1.0-alpha-4.jar:]
>     at org.keycloak.server.KeycloakServerApplication.<init>(KeycloakServerApplication.java:41) [classes:]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_09]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_09]
>     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_09]
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_09]
>     at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:282) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:259) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:85) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) [resteasy-jaxrs-2.3.2.Final.jar:]
>     at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.13.Final.jar:]
>     at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.13.Final.jar:]
>     at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.13.Final.jar:]
>     at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.13.Final.jar:]
>     at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
>
> I wonder if there is anything wrong here, w/ the
> jboss-deployment-structure.xml file of the actual WAR file from Keycloak?
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140331/73eb693e/attachment-0001.html 

From stian at redhat.com  Mon Mar 31 12:52:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 31 Mar 2014 12:52:54 -0400 (EDT)
Subject: [keycloak-dev] Update on audit
In-Reply-To: <523367176.4767703.1396284369151.JavaMail.zimbra@redhat.com>
Message-ID: <1574040906.4772312.1396284774193.JavaMail.zimbra@redhat.com>

Work completed:

* Added AuditListener SPI (https://github.com/keycloak/keycloak/blob/master/audit/api/src/main/java/org/keycloak/audit/AuditListener.java)
* Added JBoss Logging AuditListener implementation (this is used by default for all realms atm)
* Added audit events for token service, social, account management and required actions

Remaining work:

* Add a AuditProvider SPI (extends AuditListener to add querying for events)
* Add implementations of AuditProvider - atm I'm thinking a JPA and Mongo providers as a sensible starting point (with an option to remove events after N days). I've considered parsing logs, but I'm pretty sure that won't work for account management (and will also be quite limiting for admin console)
* Allow configuring audit listeners/providers for a realm through admin console
* View events associated with user in account management
* View all events in admin console
* Audit events for admin

Related:

* AuditListener/Provider could be useful for brute force protection
* AuditListener could be used to allow applications to listen for user creation/update/deletion to sync user details into a separate database / maybe we could add a UserListener interface?