From mposolda at redhat.com  Fri Apr  1 03:41:13 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 1 Apr 2016 09:41:13 +0200
Subject: [keycloak-dev] AbstractUsernameFormAuthenticator
 validateUserAndPassword process
In-Reply-To: <CAFzO_6dNAaTKPSN3Nw8P+aw-vSPX-TF=zac9P_HddC_w9e2FrQ@mail.gmail.com>
References: <CAFzO_6fQ9T_g15KKo2AfWiPBahTzFQO7HN8Lv0FW2GuR6qFWYQ@mail.gmail.com>
	<56FCFF97.7030202@redhat.com>
	<CAFzO_6dNAaTKPSN3Nw8P+aw-vSPX-TF=zac9P_HddC_w9e2FrQ@mail.gmail.com>
Message-ID: <56FE2619.20205@redhat.com>

On 31/03/16 18:17, Ariel Carrera wrote:
> Marek, that's makes sense, but, what happen when the user is known by 
> the attacker? If the brute force check is in the "isEnabled" method 
> (after password validation), the attacker guesses the password 
> successfully, the brute force protection never apply. Please check the 
> code because i am afraid that it can be a big security risk.
> If you wants I can open a new jira issue to discuss about it.
Hmm... I am missing the scenario where exactly is the security risk? 
Could you elaborate more? What I can see is:

- In case that attacker knows both username and password of user, the 
security is compromised anyway. In this case, Keycloak don't have 
possibility to differ between valid user (who knows his username and 
password) and attacker (who knows both username and password). So in 
case that user is enabled, both valid user or attacker are able to 
login. In case that user is disabled, both valid user and attacker will 
receive message "Account is disabled" (because "validatePassword" check 
passes, but "enabledUser" check fails)

- In case that attacker knows just username, the "validatePassword" 
check will fail and will be "logged" in BruteForce too. Attacker will 
receive message "Incorrect username or password"

Marek

>
> 2016-03-31 7:44 GMT-03:00 Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>>:
>
>     AFAIK one of the reasons is security. If an attacker guesses
>     username "foo", which exists, but not password of user "foo", you
>     don't want to tell him that he successfully guessed username. So
>     instead of first checking that user "foo" is disabled and display
>     the message "The user account is disabled", you rather check
>     password first and then display the message "Incorrect username or
>     password", so attacker don't have a clue if account really exists
>     or password was incorrect etc. Also if BruteForce protector is
>     enabled, you want to log the event as failed login, so we're
>     checking the password of user.
>
>     Marek
>
>
>
>     On 30/03/16 17:40, Ariel Carrera wrote:
>>     Hi, I am developing a Federation Provider, and I have a question...
>>
>>     Why the method () checks if the user "is enabled" after validate
>>     the password instead of before of the password validation?
>>
>>     AbstractUsernameFormAuthenticator.validateUserAndPassword: line
>>     141/151
>>     ...
>>             if (invalidUser(context, user)){
>>                 return false;
>>             }
>>
>>     *        if (!validatePassword(context, user, inputData)){*
>>     *            return false;*
>>     *        }*
>>
>>     *        if(!enabledUser(context, user)){*
>>     *            return false;*
>>     *        }*
>>     ...
>>
>>     If the user is disabled... why validate his password and return a
>>     password validation error message?
>>
>>     -- 
>>     Ariel Carrera
>>
>>
>>     _______________________________________________
>>     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
>
>
>
>
> -- 
> Tat?

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

From mposolda at redhat.com  Fri Apr  1 03:47:57 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 1 Apr 2016 09:47:57 +0200
Subject: [keycloak-dev] AbstractUsernameFormAuthenticator
 validateUserAndPassword process
In-Reply-To: <56FE2619.20205@redhat.com>
References: <CAFzO_6fQ9T_g15KKo2AfWiPBahTzFQO7HN8Lv0FW2GuR6qFWYQ@mail.gmail.com>
	<56FCFF97.7030202@redhat.com>
	<CAFzO_6dNAaTKPSN3Nw8P+aw-vSPX-TF=zac9P_HddC_w9e2FrQ@mail.gmail.com>
	<56FE2619.20205@redhat.com>
Message-ID: <56FE27AD.8090909@redhat.com>

On 01/04/16 09:41, Marek Posolda wrote:
> On 31/03/16 18:17, Ariel Carrera wrote:
>> Marek, that's makes sense, but, what happen when the user is known by 
>> the attacker? If the brute force check is in the "isEnabled" method 
>> (after password validation), the attacker guesses the password 
>> successfully, the brute force protection never apply. Please check 
>> the code because i am afraid that it can be a big security risk.
>> If you wants I can open a new jira issue to discuss about it.
> Hmm... I am missing the scenario where exactly is the security risk? 
> Could you elaborate more? What I can see is:
>
> - In case that attacker knows both username and password of user, the 
> security is compromised anyway. In this case, Keycloak don't have 
> possibility to differ between valid user (who knows his username and 
> password) and attacker (who knows both username and password). So in 
> case that user is enabled, both valid user or attacker are able to 
> login. In case that user is disabled, both valid user and attacker 
> will receive message "Account is disabled" (because "validatePassword" 
> check passes, but "enabledUser" check fails)
>
> - In case that attacker knows just username, the "validatePassword" 
> check will fail and will be "logged" in BruteForce too. Attacker will 
> receive message "Incorrect username or password"
Also one more point, if user account is temporarily disabled because of 
BruteForce protection, attacker won't recognize it because message will 
still be "Incorrect username or password" . He won't know that he 
guessed password. We added this recently, see some related discussion 
here : http://lists.jboss.org/pipermail/keycloak-dev/2016-March/006751.html

Marek
>
> Marek
>
>>
>> 2016-03-31 7:44 GMT-03:00 Marek Posolda <mposolda at redhat.com 
>> <mailto:mposolda at redhat.com>>:
>>
>>     AFAIK one of the reasons is security. If an attacker guesses
>>     username "foo", which exists, but not password of user "foo", you
>>     don't want to tell him that he successfully guessed username. So
>>     instead of first checking that user "foo" is disabled and display
>>     the message "The user account is disabled", you rather check
>>     password first and then display the message "Incorrect username
>>     or password", so attacker don't have a clue if account really
>>     exists or password was incorrect etc. Also if BruteForce
>>     protector is enabled, you want to log the event as failed login,
>>     so we're checking the password of user.
>>
>>     Marek
>>
>>
>>
>>     On 30/03/16 17:40, Ariel Carrera wrote:
>>>     Hi, I am developing a Federation Provider, and I have a question...
>>>
>>>     Why the method () checks if the user "is enabled" after validate
>>>     the password instead of before of the password validation?
>>>
>>>     AbstractUsernameFormAuthenticator.validateUserAndPassword: line
>>>     141/151
>>>     ...
>>>             if (invalidUser(context, user)){
>>>                 return false;
>>>             }
>>>
>>>     *        if (!validatePassword(context, user, inputData)){*
>>>     *            return false;*
>>>     *        }*
>>>
>>>     *        if(!enabledUser(context, user)){*
>>>     *            return false;*
>>>     *        }*
>>>     ...
>>>
>>>     If the user is disabled... why validate his password and return
>>>     a password validation error message?
>>>
>>>     -- 
>>>     Ariel Carrera
>>>
>>>
>>>     _______________________________________________
>>>     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
>>
>>
>>
>>
>> -- 
>> Tat?
>

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

From carreraariel at gmail.com  Fri Apr  1 08:16:13 2016
From: carreraariel at gmail.com (Ariel Carrera)
Date: Fri, 1 Apr 2016 09:16:13 -0300
Subject: [keycloak-dev] AbstractUsernameFormAuthenticator
 validateUserAndPassword process
In-Reply-To: <56FE27AD.8090909@redhat.com>
References: <CAFzO_6fQ9T_g15KKo2AfWiPBahTzFQO7HN8Lv0FW2GuR6qFWYQ@mail.gmail.com>
	<56FCFF97.7030202@redhat.com>
	<CAFzO_6dNAaTKPSN3Nw8P+aw-vSPX-TF=zac9P_HddC_w9e2FrQ@mail.gmail.com>
	<56FE2619.20205@redhat.com> <56FE27AD.8090909@redhat.com>
Message-ID: <CAFzO_6c+Yue2Kc2MEqV1XmkLPUcn_BZkF3yYrpGpJBAMoV20UA@mail.gmail.com>

Hi marek, look at jira for more information. I sent a jira issue with the
steps to reproduce the big security risk in Form authorization with "brute
force detection". I had check grant validation and it is ok.
The code focus on protect the username but forget to protect the password.

Example.
Username: admin
Pass: 1234
Brute force after 2 errors.

Step 1: user admin, pass 1 -> invalid user or pass
Step 2: user admin, pass 12 -> invalid user or pass
Step 3: user admin, pass 123 -> invalid user or pass (brute force not
apply, but is working now)
Step 4: user admin, pass 1234 -> temporary locked (password ok!!!, brute
force apply)
Bingo...you have the admin password
El 1/4/2016 4:48, "Marek Posolda" <mposolda at redhat.com> escribi?:

> On 01/04/16 09:41, Marek Posolda wrote:
>
> On 31/03/16 18:17, Ariel Carrera wrote:
>
> Marek, that's makes sense, but, what happen when the user is known by the
> attacker? If the brute force check is in the "isEnabled" method (after
> password validation), the attacker guesses the password successfully, the
> brute force protection never apply. Please check the code because i am
> afraid that it can be a big security risk.
> If you wants I can open a new jira issue to discuss about it.
>
> Hmm... I am missing the scenario where exactly is the security risk? Could
> you elaborate more? What I can see is:
>
> - In case that attacker knows both username and password of user, the
> security is compromised anyway. In this case, Keycloak don't have
> possibility to differ between valid user (who knows his username and
> password) and attacker (who knows both username and password). So in case
> that user is enabled, both valid user or attacker are able to login. In
> case that user is disabled, both valid user and attacker will receive
> message "Account is disabled" (because "validatePassword" check passes, but
> "enabledUser" check fails)
>
> - In case that attacker knows just username, the "validatePassword" check
> will fail and will be "logged" in BruteForce too. Attacker will receive
> message "Incorrect username or password"
>
> Also one more point, if user account is temporarily disabled because of
> BruteForce protection, attacker won't recognize it because message will
> still be "Incorrect username or password" . He won't know that he guessed
> password. We added this recently, see some related discussion here :
> http://lists.jboss.org/pipermail/keycloak-dev/2016-March/006751.html
>
> Marek
>
>
> Marek
>
>
> 2016-03-31 7:44 GMT-03:00 Marek Posolda <mposolda at redhat.com>:
>
>> AFAIK one of the reasons is security. If an attacker guesses username
>> "foo", which exists, but not password of user "foo", you don't want to tell
>> him that he successfully guessed username. So instead of first checking
>> that user "foo" is disabled and display the message "The user account is
>> disabled", you rather check password first and then display the message
>> "Incorrect username or password", so attacker don't have a clue if account
>> really exists or password was incorrect etc. Also if BruteForce protector
>> is enabled, you want to log the event as failed login, so we're checking
>> the password of user.
>>
>> Marek
>>
>>
>>
>> On 30/03/16 17:40, Ariel Carrera wrote:
>>
>> Hi, I am developing a Federation Provider, and I have a question...
>>
>> Why the method () checks if the user "is enabled" after validate the
>> password instead of before of the password validation?
>>
>> AbstractUsernameFormAuthenticator.validateUserAndPassword: line 141/151
>> ...
>>         if (invalidUser(context, user)){
>>             return false;
>>         }
>>
>> *        if (!validatePassword(context, user, inputData)){*
>> *            return false;*
>> *        }*
>>
>> *        if(!enabledUser(context, user)){*
>> *            return false;*
>> *        }*
>> ...
>>
>> If the user is disabled... why validate his password and return a
>> password validation error message?
>>
>> --
>> Ariel Carrera
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>
> --
> Tat?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160401/a520d5f3/attachment-0001.html 

From bburke at redhat.com  Fri Apr  1 09:11:20 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 1 Apr 2016 09:11:20 -0400
Subject: [keycloak-dev] Conceptual Questions
In-Reply-To: <56FD91F5.4030700@redhat.com>
References: <56E9DFB2.6070802@redhat.com>
	<CAJgngAex--XycSmcX82YSLAjLpr6p789GvW2i340PZSccW-j7g@mail.gmail.com>
	<56FD91F5.4030700@redhat.com>
Message-ID: <56FE7378.4000907@redhat.com>

John,

I saw your questions.  They are very good and helpful and show that we 
have not articulated things very well in our documentation.  I have not 
had enough time to answer them as our F2F created a huge backlog of 
stuff we've all had to catch up on the last few weeks.

On 3/31/2016 5:09 PM, John Dennis wrote:
> On 03/22/2016 03:40 AM, Stian Thorgersen wrote:
>> That's a very long list of questions. Have you read through our
>> documentation? I would hope it at least answers some of these questions.
>> If not then breaking this list into smaller emails would make it easier
>> to answer. Answering all these questions in one go is a fairly time
>> consuming job.
> I'm not looking to waste anyone's time. I've read all the documentation,
> watched all the keycloak videos, read the relevant RFC's and browsed the
> Keycloak source code. These are the questions I was left with after
> having done my homework :-)
>
> I recognize the Keycloak team is at a very busy juncture at this point
> in time. Perhaps the best course forward would be a recordable
> conference call the details of which are probably best handled off-list.
>
>

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


From sthorger at redhat.com  Mon Apr  4 01:43:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 4 Apr 2016 07:43:29 +0200
Subject: [keycloak-dev] Conceptual Questions
In-Reply-To: <56FD91F5.4030700@redhat.com>
References: <56E9DFB2.6070802@redhat.com>
	<CAJgngAex--XycSmcX82YSLAjLpr6p789GvW2i340PZSccW-j7g@mail.gmail.com>
	<56FD91F5.4030700@redhat.com>
Message-ID: <CAJgngAfDSn0v7Hw8QVmLoAq3MtskdvGcVrjywT-Q1Xpf+pZC9w@mail.gmail.com>

+1 To conference call.

Looks like we have one on Thursday is that suitable or do we need a
separate session?



On 31 March 2016 at 23:09, John Dennis <jdennis at redhat.com> wrote:

> On 03/22/2016 03:40 AM, Stian Thorgersen wrote:
>
>> That's a very long list of questions. Have you read through our
>> documentation? I would hope it at least answers some of these questions.
>> If not then breaking this list into smaller emails would make it easier
>> to answer. Answering all these questions in one go is a fairly time
>> consuming job.
>>
>
> I'm not looking to waste anyone's time. I've read all the documentation,
> watched all the keycloak videos, read the relevant RFC's and browsed the
> Keycloak source code. These are the questions I was left with after having
> done my homework :-)
>
> I recognize the Keycloak team is at a very busy juncture at this point in
> time. Perhaps the best course forward would be a recordable conference call
> the details of which are probably best handled off-list.
>
>
> --
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160404/729318ec/attachment.html 

From mposolda at redhat.com  Mon Apr  4 03:31:53 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 4 Apr 2016 09:31:53 +0200
Subject: [keycloak-dev] Expected behaviour for rememberMe?
In-Reply-To: <5A171A64-64FC-431F-844A-E37E5A92892E@redhat.com>
References: <56FD1F76.1090908@redhat.com>
	<5A171A64-64FC-431F-844A-E37E5A92892E@redhat.com>
Message-ID: <57021869.3050606@redhat.com>

Seems there are 2 things here:

1) Username "hint" provided by KEYCLOAK_REMEMBERME cookie. IMO this 
cookie should be deleted only when:
- User explicitly clicked on logout and maually logout himself
- User click on "Login" button on login screen without the rememberme 
checkbox checked

IMO it shouldn't be deleted when SSO cookie is expired, which is current 
behaviour and should be changed IMO. In other words, I expect the 
scenario working like:
- User logged with "rememberMe" checkbox on
- User closed the browser
- After a month, user returned back to the application. His SSO session 
is expired, but KEYCLOAK_REMEMBERME cookie won't be deleted, so on login 
screen he will see the prefilled username and rememberMe checkbox 
switched to "on"


2) Persistent KEYCLOAK_IDENTITY cookie when rememberMe is switched to 
on. I can't see how it can work when session is expired as it relies on 
session in the cookie value. On the other hand, rememberMe shouldn't 
rely on "SSO Session idle timeout" IMO.  SSO IDle timeout is only 30 
minutes by default. So current behaviour is, that when user closes his 
browser, he needs to open in again and being re-authenticated only when 
he do within 30 minutes, which is bit of pointless IMO.

I would suggest to change the behaviour like this:
- When userSession is marked as rememberMe, then cleaner thread will 
take into account just "SSO Max Lifespan" timeout, but not SSO Idle timeout
- During verification of SSO cookie re-authentication and when session 
is rememberMe, we will take into account just SSO Max Lifespan of 
session, but not SSO Idle timeout
Refreshing of tokens will still take SSO Idle timeout just like now.

If we not change the behaviour like this, we should at least update 
"RememberMe" docs and tooltip to make it more clear what the behaviour 
would be in various cases.
WDYT?
Marek

On 31/03/16 16:26, Libor Krzyzanek wrote:
> I read docs today 
> http://keycloak.github.io/docs/userguide/keycloak-server/html/timeouts.html#d4e2630
>  and my understanding is that user should keep logged in after either 
> browser restart or session expiration.
> My tests shows that after session expiration (set to 1 min) I have to 
> log in again.
>
> Thanks,
>
> Libor Krzy?anek
> Principal Software Engineer
> Red Hat Developers | Engineering
>
>> On Mar 31, 2016, at 3:00 PM, Marek Posolda <mposolda at redhat.com 
>> <mailto:mposolda at redhat.com>> wrote:
>>
>> Followup on the issue by Libor [1] . I can confirm to see the same
>> behaviour in the OOTB Keycloak, like Libor described in the JIRA. In
>> other words, when you refresh account page (
>> http://localhost:8080/auth/realms/myrealm/account ) but the UserSession
>> referenced from KEYCLOAK_IDENTITY cookie is expired, then all cookies
>> including KEYCLOAK_REMEMBERME are expired too.
>>
>> IMO RememberMe cookie shouldn't be expired when session is expired.
>> We're using the rememberMe cookie as hint for username on the login
>> page. So even if user returns to page after a month, I am not seeing
>> anything bad that rememberMe cookie is still valid and user will see
>> "hint" with his username on login page and rememberMe checkbox checked
>> even if session was expired already for a long time. IMO the only
>> situation when we should expire KEYCLOAK_REMEMBERME cookie is, when user
>> unchecks the "Remember me" checkbox on login page.
>>
>> [1] https://issues.jboss.org/browse/ORG-2956
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160404/3e7ce2b0/attachment.html 

From sthorger at redhat.com  Mon Apr  4 04:44:34 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 4 Apr 2016 10:44:34 +0200
Subject: [keycloak-dev] Expected behaviour for rememberMe?
In-Reply-To: <57021869.3050606@redhat.com>
References: <56FD1F76.1090908@redhat.com>
	<5A171A64-64FC-431F-844A-E37E5A92892E@redhat.com>
	<57021869.3050606@redhat.com>
Message-ID: <CAJgngAfpOdhtMzJVFZ0RKcv__pcXhkhLDoKjgEOn39bSuDKPvw@mail.gmail.com>

On 4 April 2016 at 09:31, Marek Posolda <mposolda at redhat.com> wrote:

> Seems there are 2 things here:
>
> 1) Username "hint" provided by KEYCLOAK_REMEMBERME cookie. IMO this cookie
> should be deleted only when:
> - User explicitly clicked on logout and maually logout himself
> - User click on "Login" button on login screen without the rememberme
> checkbox checked
>
> IMO it shouldn't be deleted when SSO cookie is expired, which is current
> behaviour and should be changed IMO. In other words, I expect the scenario
> working like:
> - User logged with "rememberMe" checkbox on
> - User closed the browser
> - After a month, user returned back to the application. His SSO session is
> expired, but KEYCLOAK_REMEMBERME cookie won't be deleted, so on login
> screen he will see the prefilled username and rememberMe checkbox switched
> to "on"
>

Create a JIRA to request remember me cookie to not be removed. However, we
need some way of configuring expiration of the cookie. This would be for
2.x.


>
>
> 2) Persistent KEYCLOAK_IDENTITY cookie when rememberMe is switched to on.
> I can't see how it can work when session is expired as it relies on session
> in the cookie value. On the other hand, rememberMe shouldn't rely on "SSO
> Session idle timeout" IMO.  SSO IDle timeout is only 30 minutes by default.
> So current behaviour is, that when user closes his browser, he needs to
> open in again and being re-authenticated only when he do within 30 minutes,
> which is bit of pointless IMO.
>
> I would suggest to change the behaviour like this:
> - When userSession is marked as rememberMe, then cleaner thread will take
> into account just "SSO Max Lifespan" timeout, but not SSO Idle timeout
> - During verification of SSO cookie re-authentication and when session is
> rememberMe, we will take into account just SSO Max Lifespan of session, but
> not SSO Idle timeout
> Refreshing of tokens will still take SSO Idle timeout just like now.
>
> If we not change the behaviour like this, we should at least update
> "RememberMe" docs and tooltip to make it more clear what the behaviour
> would be in various cases.
> WDYT?
>

We've already discussed this and there's a JIRA requesting it (
https://issues.jboss.org/browse/KEYCLOAK-1267). The default behavior should
be that SSO Idle timeout is taken into account, but there should be an
realm option to ignore it and only rely on SSO Max lifespan. This is also
for 2.x.


>
> Marek
>
>
> On 31/03/16 16:26, Libor Krzyzanek wrote:
>
> I read docs today
> http://keycloak.github.io/docs/userguide/keycloak-server/html/timeouts.html#d4e2630
>  and my understanding is that user should keep logged in after either
> browser restart or session expiration.
> My tests shows that after session expiration (set to 1 min) I have to log
> in again.
>
> Thanks,
>
> Libor Krzy?anek
> Principal Software Engineer
> Red Hat Developers | Engineering
>
> On Mar 31, 2016, at 3:00 PM, Marek Posolda <mposolda at redhat.com> wrote:
>
> Followup on the issue by Libor [1] . I can confirm to see the same
> behaviour in the OOTB Keycloak, like Libor described in the JIRA. In
> other words, when you refresh account page (
> http://localhost:8080/auth/realms/myrealm/account ) but the UserSession
> referenced from KEYCLOAK_IDENTITY cookie is expired, then all cookies
> including KEYCLOAK_REMEMBERME are expired too.
>
> IMO RememberMe cookie shouldn't be expired when session is expired.
> We're using the rememberMe cookie as hint for username on the login
> page. So even if user returns to page after a month, I am not seeing
> anything bad that rememberMe cookie is still valid and user will see
> "hint" with his username on login page and rememberMe checkbox checked
> even if session was expired already for a long time. IMO the only
> situation when we should expire KEYCLOAK_REMEMBERME cookie is, when user
> unchecks the "Remember me" checkbox on login page.
>
> [1] https://issues.jboss.org/browse/ORG-2956
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160404/35427ef3/attachment-0001.html 

From sthorger at redhat.com  Mon Apr  4 04:50:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 4 Apr 2016 10:50:47 +0200
Subject: [keycloak-dev] Expected behaviour for rememberMe?
In-Reply-To: <CAJgngAfpOdhtMzJVFZ0RKcv__pcXhkhLDoKjgEOn39bSuDKPvw@mail.gmail.com>
References: <56FD1F76.1090908@redhat.com>
	<5A171A64-64FC-431F-844A-E37E5A92892E@redhat.com>
	<57021869.3050606@redhat.com>
	<CAJgngAfpOdhtMzJVFZ0RKcv__pcXhkhLDoKjgEOn39bSuDKPvw@mail.gmail.com>
Message-ID: <CAJgngAcBOCJjvFp_XkvUsrA5uFgz2yQwVOAZuGnS1KS1Q_gOSg@mail.gmail.com>

On 4 April 2016 at 10:44, Stian Thorgersen <sthorger at redhat.com> wrote:

>
> On 4 April 2016 at 09:31, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Seems there are 2 things here:
>>
>> 1) Username "hint" provided by KEYCLOAK_REMEMBERME cookie. IMO this
>> cookie should be deleted only when:
>> - User explicitly clicked on logout and maually logout himself
>> - User click on "Login" button on login screen without the rememberme
>> checkbox checked
>>
>> IMO it shouldn't be deleted when SSO cookie is expired, which is current
>> behaviour and should be changed IMO. In other words, I expect the scenario
>> working like:
>> - User logged with "rememberMe" checkbox on
>> - User closed the browser
>> - After a month, user returned back to the application. His SSO session
>> is expired, but KEYCLOAK_REMEMBERME cookie won't be deleted, so on login
>> screen he will see the prefilled username and rememberMe checkbox switched
>> to "on"
>>
>
> Create a JIRA to request remember me cookie to not be removed. However, we
> need some way of configuring expiration of the cookie. This would be for
> 2.x.
>
>
>>
>>
>> 2) Persistent KEYCLOAK_IDENTITY cookie when rememberMe is switched to on.
>> I can't see how it can work when session is expired as it relies on session
>> in the cookie value. On the other hand, rememberMe shouldn't rely on "SSO
>> Session idle timeout" IMO.  SSO IDle timeout is only 30 minutes by default.
>> So current behaviour is, that when user closes his browser, he needs to
>> open in again and being re-authenticated only when he do within 30 minutes,
>> which is bit of pointless IMO.
>>
>> I would suggest to change the behaviour like this:
>> - When userSession is marked as rememberMe, then cleaner thread will take
>> into account just "SSO Max Lifespan" timeout, but not SSO Idle timeout
>> - During verification of SSO cookie re-authentication and when session is
>> rememberMe, we will take into account just SSO Max Lifespan of session, but
>> not SSO Idle timeout
>> Refreshing of tokens will still take SSO Idle timeout just like now.
>>
>> If we not change the behaviour like this, we should at least update
>> "RememberMe" docs and tooltip to make it more clear what the behaviour
>> would be in various cases.
>> WDYT?
>>
>
> We've already discussed this and there's a JIRA requesting it (
> https://issues.jboss.org/browse/KEYCLOAK-1267). The default behavior
> should be that SSO Idle timeout is taken into account, but there should be
> an realm option to ignore it and only rely on SSO Max lifespan. This is
> also for 2.x.
>

Actually, thinking about this some more IMO we should either reject
KEYCLOAK-1267 or add separate idle/max configuration for remember me, not
just ignore. Having user sessions that doesn't take SSO Idle into account
would potentially result in a large number of unused user sessions left in
the system. Especially if SSO Max is large. It could be users clicked it by
mistake in incognito mode, they manually cleared cookies, they re-installed
the machine, etc.


>
>
>>
>> Marek
>>
>>
>> On 31/03/16 16:26, Libor Krzyzanek wrote:
>>
>> I read docs today
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/timeouts.html#d4e2630
>>  and my understanding is that user should keep logged in after either
>> browser restart or session expiration.
>> My tests shows that after session expiration (set to 1 min) I have to log
>> in again.
>>
>> Thanks,
>>
>> Libor Krzy?anek
>> Principal Software Engineer
>> Red Hat Developers | Engineering
>>
>> On Mar 31, 2016, at 3:00 PM, Marek Posolda <mposolda at redhat.com> wrote:
>>
>> Followup on the issue by Libor [1] . I can confirm to see the same
>> behaviour in the OOTB Keycloak, like Libor described in the JIRA. In
>> other words, when you refresh account page (
>> http://localhost:8080/auth/realms/myrealm/account ) but the UserSession
>> referenced from KEYCLOAK_IDENTITY cookie is expired, then all cookies
>> including KEYCLOAK_REMEMBERME are expired too.
>>
>> IMO RememberMe cookie shouldn't be expired when session is expired.
>> We're using the rememberMe cookie as hint for username on the login
>> page. So even if user returns to page after a month, I am not seeing
>> anything bad that rememberMe cookie is still valid and user will see
>> "hint" with his username on login page and rememberMe checkbox checked
>> even if session was expired already for a long time. IMO the only
>> situation when we should expire KEYCLOAK_REMEMBERME cookie is, when user
>> unchecks the "Remember me" checkbox on login page.
>>
>> [1] https://issues.jboss.org/browse/ORG-2956
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160404/daece776/attachment.html 

From sthorger at redhat.com  Mon Apr  4 05:26:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 4 Apr 2016 11:26:47 +0200
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAPyAMoYOLvRGmuffG+s6pdE2jAAC0bKHMPwh=mhCjHqJywpmXA@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
	<CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
	<CAPyAMoYOLvRGmuffG+s6pdE2jAAC0bKHMPwh=mhCjHqJywpmXA@mail.gmail.com>
Message-ID: <CAJgngAe_jCkgwwULQw791cCL+YZr_QuSuwsR0NsdzFQswnE=hA@mail.gmail.com>

I wonder if we should have a Keycloak extensions repository where we could
place things like this rather than adding directly to master.

On 31 March 2016 at 20:18, Thomas Raehalme <thomas.raehalme at aitiofinland.com
> wrote:

> Hi,
>
> On Thu, Mar 31, 2016 at 4:38 PM, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> would you mind sharing your keycloak configuration with a JMS
>> resource-adapter?
>>
>
> Here are the changes I made to standalone/configuration/standalone.xml:
>
> 1. Added the following extension under /server/extensions:
>
> <extension module="org.wildfly.extension.messaging-activemq"/>
>
> 2. Added the following subsystem under /server/profile:
>
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
>     <server name="default">
>         <security enabled="false" /> <!-- I didn't need to use security as
> everything was localhost -->
>         <remote-acceptor name="netty" socket-binding="messaging"/>
>         <remote-connector name="netty" socket-binding="messaging"/>
>         <in-vm-acceptor name="in-vm" server-id="0"/>
>         <in-vm-connector name="in-vm" server-id="0"/>
>         <pooled-connection-factory name="activemq-ra"
>                     transaction="xa" connectors="in-vm"
>                     entries="java:/ConnectionFactory java:/JmsXA
> java:jboss/DefaultJMSConnectionFactory"/>
>         <jms-topic name="KeycloakEvents" entries="jms/KeycloakEvents
> java:jboss/exported/jms/KeycloakEvents" />
>     </server>
> </subsystem>
>
> 3. Added the following socket-binding under /server/socket-binding-group:
>
> <socket-binding name="messaging" port="61616"/>
>
> This enabled my external process to listen to the JMS topic.
>
> I attached a full example to this message. The changes have been marked
> with <!-- keycloak-events-jms -->.
>
> Did you manage to configure a new resource-adapter via jboss-cli?
>>
>
> No, I haven't used jboss-cli but modified the configuration file directly.
>
> My implementation of KEYCLOAK-2302 can be found at Github:
> https://github.com/raehalme/keycloak/tree/KEYCLOAK-2302.
>
> I have not sent a PR as I have yet to complete the Arquillian integration
> tests requested by Stian. Other work has kept me busy and I haven't had a
> chance to even rebase against 1.9.x.
>
> Best regards,
> Thomas
>
>
> _______________________________________________
> 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/20160404/6e9850f0/attachment.html 

From thomas.raehalme at aitiofinland.com  Mon Apr  4 07:44:19 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Mon, 4 Apr 2016 14:44:19 +0300
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAJgngAe_jCkgwwULQw791cCL+YZr_QuSuwsR0NsdzFQswnE=hA@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
	<CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
	<CAPyAMoYOLvRGmuffG+s6pdE2jAAC0bKHMPwh=mhCjHqJywpmXA@mail.gmail.com>
	<CAJgngAe_jCkgwwULQw791cCL+YZr_QuSuwsR0NsdzFQswnE=hA@mail.gmail.com>
Message-ID: <CAPyAMobupSFA2+YHZhdcmDMiyB+bz0OzR=wLr437j2BR86o1SA@mail.gmail.com>

It would probably be a good idea although I think this JMS publishing is
such a basic feature that it should be part of the core package.

If you have a chance to help me get started with the Arquillian part, I'm
happy to send the PR. I should have time to work on this again within the
next week or so.

Best regards,
Thomas


On Mon, Apr 4, 2016 at 12:26 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I wonder if we should have a Keycloak extensions repository where we could
> place things like this rather than adding directly to master.
>
> On 31 March 2016 at 20:18, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> Hi,
>>
>> On Thu, Mar 31, 2016 at 4:38 PM, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> would you mind sharing your keycloak configuration with a JMS
>>> resource-adapter?
>>>
>>
>> Here are the changes I made to standalone/configuration/standalone.xml:
>>
>> 1. Added the following extension under /server/extensions:
>>
>> <extension module="org.wildfly.extension.messaging-activemq"/>
>>
>> 2. Added the following subsystem under /server/profile:
>>
>> <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
>>     <server name="default">
>>         <security enabled="false" /> <!-- I didn't need to use security
>> as everything was localhost -->
>>         <remote-acceptor name="netty" socket-binding="messaging"/>
>>         <remote-connector name="netty" socket-binding="messaging"/>
>>         <in-vm-acceptor name="in-vm" server-id="0"/>
>>         <in-vm-connector name="in-vm" server-id="0"/>
>>         <pooled-connection-factory name="activemq-ra"
>>                     transaction="xa" connectors="in-vm"
>>                     entries="java:/ConnectionFactory java:/JmsXA
>> java:jboss/DefaultJMSConnectionFactory"/>
>>         <jms-topic name="KeycloakEvents" entries="jms/KeycloakEvents
>> java:jboss/exported/jms/KeycloakEvents" />
>>     </server>
>> </subsystem>
>>
>> 3. Added the following socket-binding under /server/socket-binding-group:
>>
>> <socket-binding name="messaging" port="61616"/>
>>
>> This enabled my external process to listen to the JMS topic.
>>
>> I attached a full example to this message. The changes have been marked
>> with <!-- keycloak-events-jms -->.
>>
>> Did you manage to configure a new resource-adapter via jboss-cli?
>>>
>>
>> No, I haven't used jboss-cli but modified the configuration file directly.
>>
>> My implementation of KEYCLOAK-2302 can be found at Github:
>> https://github.com/raehalme/keycloak/tree/KEYCLOAK-2302.
>>
>> I have not sent a PR as I have yet to complete the Arquillian integration
>> tests requested by Stian. Other work has kept me busy and I haven't had a
>> chance to even rebase against 1.9.x.
>>
>> Best regards,
>> Thomas
>>
>>
>> _______________________________________________
>> 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/20160404/6f6057e8/attachment-0001.html 

From mposolda at redhat.com  Mon Apr  4 08:58:15 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 4 Apr 2016 14:58:15 +0200
Subject: [keycloak-dev] Expected behaviour for rememberMe?
In-Reply-To: <CAJgngAcBOCJjvFp_XkvUsrA5uFgz2yQwVOAZuGnS1KS1Q_gOSg@mail.gmail.com>
References: <56FD1F76.1090908@redhat.com>
	<5A171A64-64FC-431F-844A-E37E5A92892E@redhat.com>
	<57021869.3050606@redhat.com>
	<CAJgngAfpOdhtMzJVFZ0RKcv__pcXhkhLDoKjgEOn39bSuDKPvw@mail.gmail.com>
	<CAJgngAcBOCJjvFp_XkvUsrA5uFgz2yQwVOAZuGnS1KS1Q_gOSg@mail.gmail.com>
Message-ID: <570264E7.8000206@redhat.com>

On 04/04/16 10:50, Stian Thorgersen wrote:
>
>
> On 4 April 2016 at 10:44, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>
>     On 4 April 2016 at 09:31, Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>> wrote:
>
>         Seems there are 2 things here:
>
>         1) Username "hint" provided by KEYCLOAK_REMEMBERME cookie. IMO
>         this cookie should be deleted only when:
>         - User explicitly clicked on logout and maually logout himself
>         - User click on "Login" button on login screen without the
>         rememberme checkbox checked
>
>         IMO it shouldn't be deleted when SSO cookie is expired, which
>         is current behaviour and should be changed IMO. In other
>         words, I expect the scenario working like:
>         - User logged with "rememberMe" checkbox on
>         - User closed the browser
>         - After a month, user returned back to the application. His
>         SSO session is expired, but KEYCLOAK_REMEMBERME cookie won't
>         be deleted, so on login screen he will see the prefilled
>         username and rememberMe checkbox switched to "on"
>
>
>     Create a JIRA to request remember me cookie to not be removed.
>     However, we need some way of configuring expiration of the cookie.
>     This would be for 2.x.
>
Ok, Thanks. Created https://issues.jboss.org/browse/KEYCLOAK-2741
>
>
>
>         2) Persistent KEYCLOAK_IDENTITY cookie when rememberMe is
>         switched to on. I can't see how it can work when session is
>         expired as it relies on session in the cookie value. On the
>         other hand, rememberMe shouldn't rely on "SSO Session idle
>         timeout" IMO.  SSO IDle timeout is only 30 minutes by default.
>         So current behaviour is, that when user closes his browser, he
>         needs to open in again and being re-authenticated only when he
>         do within 30 minutes, which is bit of pointless IMO.
>
>         I would suggest to change the behaviour like this:
>         - When userSession is marked as rememberMe, then cleaner
>         thread will take into account just "SSO Max Lifespan" timeout,
>         but not SSO Idle timeout
>         - During verification of SSO cookie re-authentication and when
>         session is rememberMe, we will take into account just SSO Max
>         Lifespan of session, but not SSO Idle timeout
>         Refreshing of tokens will still take SSO Idle timeout just
>         like now.
>
>         If we not change the behaviour like this, we should at least
>         update "RememberMe" docs and tooltip to make it more clear
>         what the behaviour would be in various cases.
>         WDYT?
>
>
>     We've already discussed this and there's a JIRA requesting it
>     (https://issues.jboss.org/browse/KEYCLOAK-1267). The default
>     behavior should be that SSO Idle timeout is taken into account,
>     but there should be an realm option to ignore it and only rely on
>     SSO Max lifespan. This is also for 2.x.
>
>
> Actually, thinking about this some more IMO we should either reject 
> KEYCLOAK-1267 or add separate idle/max configuration for remember me, 
> not just ignore. Having user sessions that doesn't take SSO Idle into 
> account would potentially result in a large number of unused user 
> sessions left in the system. Especially if SSO Max is large. It could 
> be users clicked it by mistake in incognito mode, they manually 
> cleared cookies, they re-installed the machine, etc.
+1 to add separate timeouts for rememberMe. We can have those timeouts 
available in UI just if realm is selected to have "Remember me" enabled 
(Same like the timeout for KEYCLOAK_REMEMBERME cookie specified in 
KEYCLOAK-2741 )

Marek
>
>
>         Marek
>
>
>         On 31/03/16 16:26, Libor Krzyzanek wrote:
>>         I read docs today
>>         http://keycloak.github.io/docs/userguide/keycloak-server/html/timeouts.html#d4e2630
>>          and my understanding is that user should keep logged in
>>         after either browser restart or session expiration.
>>         My tests shows that after session expiration (set to 1 min) I
>>         have to log in again.
>>
>>         Thanks,
>>
>>         Libor Krzy?anek
>>         Principal Software Engineer
>>         Red Hat Developers | Engineering
>>
>>>         On Mar 31, 2016, at 3:00 PM, Marek Posolda
>>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>
>>>         Followup on the issue by Libor [1] . I can confirm to see
>>>         the same
>>>         behaviour in the OOTB Keycloak, like Libor described in the
>>>         JIRA. In
>>>         other words, when you refresh account page (
>>>         http://localhost:8080/auth/realms/myrealm/account ) but the
>>>         UserSession
>>>         referenced from KEYCLOAK_IDENTITY cookie is expired, then
>>>         all cookies
>>>         including KEYCLOAK_REMEMBERME are expired too.
>>>
>>>         IMO RememberMe cookie shouldn't be expired when session is
>>>         expired.
>>>         We're using the rememberMe cookie as hint for username on
>>>         the login
>>>         page. So even if user returns to page after a month, I am
>>>         not seeing
>>>         anything bad that rememberMe cookie is still valid and user
>>>         will see
>>>         "hint" with his username on login page and rememberMe
>>>         checkbox checked
>>>         even if session was expired already for a long time. IMO the
>>>         only
>>>         situation when we should expire KEYCLOAK_REMEMBERME cookie
>>>         is, when user
>>>         unchecks the "Remember me" checkbox on login page.
>>>
>>>         [1] https://issues.jboss.org/browse/ORG-2956
>>>
>>>         Marek
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

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

From ssilvert at redhat.com  Mon Apr  4 16:17:23 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 04 Apr 2016 16:17:23 -0400
Subject: [keycloak-dev] Migration of testsuite's OAuthClient
Message-ID: <5702CBD3.40809@redhat.com>

This PR includes the migration of OAuthClient from the old testsuite to 
the new arquillian-based testsuite:
https://github.com/keycloak/keycloak/pull/2485

There was already another class named OAuthClient in 
org.keycloak.testsuite.util.  So to avoid confusion, this one is named 
org.keycloak.testsuite.MigratedOAuthClient.

Except for the name, MigratedOAuthClient is identical to the one in the 
old testsuite.  So it should work with migrated tests.  I've already 
used it in several of these tests.

There is one slight difference in the way it obtains the baseUrl.  I 
have migrated the Constants class and renamed it to MigratedConstants.  
Instead of the url being hard-coded as in the old testsuite, this url is 
obtained through a call to 
AuthServerTestEnricher.getAuthServerContextRoot().

Stan

From 00hf11 at gmail.com  Mon Apr  4 17:41:58 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Mon, 4 Apr 2016 18:41:58 -0300
Subject: [keycloak-dev] NPE with mvn install
Message-ID: <CABv=XZUhLRBe+dT4dGQPsLfsDud49OTyKQMJHwBFkCg-abb4FQ@mail.gmail.com>

hi folks,

I'm following the README.md

I did 'mvn install' and get a NPE and build failure

https://gist.github.com/helio-frota/f4da18e77526fb3e5dc89935f5226e0f

I need to do [setup/config] something different ?

Best regards,
helio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160404/51b5e1aa/attachment-0001.html 

From 00hf11 at gmail.com  Mon Apr  4 18:12:41 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Mon, 4 Apr 2016 19:12:41 -0300
Subject: [keycloak-dev] NPE with mvn install
In-Reply-To: <CABv=XZUhLRBe+dT4dGQPsLfsDud49OTyKQMJHwBFkCg-abb4FQ@mail.gmail.com>
References: <CABv=XZUhLRBe+dT4dGQPsLfsDud49OTyKQMJHwBFkCg-abb4FQ@mail.gmail.com>
Message-ID: <CABv=XZXGYRJweAB0S30CBgPgAsscfv3LzkrQJEVi=5yYsTCeNg@mail.gmail.com>

Hi folks,

I ran for the second time and the error did not appear.

[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 14:47 min
[INFO] Finished at: 2016-04-04T19:10:15-03:00
[INFO] Final Memory: 202M/924M
[INFO]
------------------------------------------------------------------------


On Mon, Apr 4, 2016 at 6:41 PM, Helio Frota <00hf11 at gmail.com> wrote:

> hi folks,
>
> I'm following the README.md
>
> I did 'mvn install' and get a NPE and build failure
>
> https://gist.github.com/helio-frota/f4da18e77526fb3e5dc89935f5226e0f
>
> I need to do [setup/config] something different ?
>
> Best regards,
> helio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160404/826eb270/attachment.html 

From bburke at redhat.com  Mon Apr  4 21:21:22 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 4 Apr 2016 21:21:22 -0400
Subject: [keycloak-dev] cache fixes/changes
Message-ID: <57031312.30801@redhat.com>

FYI:

KEYCLOAK-2669 showed that if you remove a role, Clients and Groups are 
not invalidated and you get invalid/stale scope mappings and group/role 
mappings.  I fixed this by extending the stream query that is already 
being done when a role is being removed.

Also, whenever something is invalidated, any Adapter instances 
associated with the session are now invalidated automatically.  This 
solves the problem with a reference being stale in the same tx if the 
cache was indirectly invalidated.

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


From sthorger at redhat.com  Tue Apr  5 01:58:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Apr 2016 07:58:13 +0200
Subject: [keycloak-dev] Added DB indexes
In-Reply-To: <56FD1597.2@redhat.com>
References: <56FCFB86.6020208@redhat.com>
	<CAK-7U1hGU3WxneDOxWwO7HFyi-6zOgf=V=gg-v6x_Q9DNiME0A@mail.gmail.com>
	<56FD1597.2@redhat.com>
Message-ID: <CAJgngAf96HbTRx0m+hnY2Hd3+TB8RT5EkKNTM4pxBijte15H-Q@mail.gmail.com>

It shouldn't be necessary for a DBA to tweak the scheme to get decent
performance, we need to make sure the required indexes are there already.

On 31 March 2016 at 14:18, Marek Posolda <mposolda at redhat.com> wrote:

> On 31/03/16 13:59, Thomas Darimont wrote:
>
> Hello Marek,
>
> thanks f?r this interesting hint - our postgres admin recommended the
> following script to me to find foreig-key index candidates:
>
> https://github.com/pgexperts/pgx_scripts/blob/master/indexes/fk_no_index.sql
>
> Running that an a fresh keycloak postgres db will return no results... but
> if you disable the where condition (that checks for usage)
> at the end you'll get an IMHO useful list of index candidates.
> I put up a gist with the modified query and results here:
> <https://gist.github.com/thomasdarimont/992aaad6af704f40fd4483af3d42290e>
> https://gist.github.com/thomasdarimont/992aaad6af704f40fd4483af3d42290e
>
> Thanks Thomas for the interesting script!
>
> I've actually didn't add indexes to all foreign keys, but just to those,
> which are widely used and are supposed to contain big number of records. So
> especially the tables related to user model. Also I needed to add some
> indexes to columns, which are not foreign keys (those were needed for both
> MySQL and PostgreSQL), for example EMAIL of USER_ENTITY table as Keycloak
> often needs to lookup users by email.
>
> Marek
>
>
> Cheers,
> Thomas
>
> 2016-03-31 12:27 GMT+02:00 Marek Posolda <mposolda at redhat.com>:
>
>> I've did loads of testing for create/load/delete big number of users
>> into database and I've send PR for add some additional indexes into
>> database to improve performance of operations with big number of users
>> in DB - https://github.com/keycloak/keycloak/pull/2456
>>
>> Note that adding DB indexes is tricky as the performance gain (or loss)
>> might be highly dependent on underlying database. Some example:
>>
>> 1) PostgreSQL is adding the indexes by default just for primary keys and
>> unique constraints. But it doesn't add indexes for foreign keys. So when
>> you have 50K users in DB and 150K role mappings (each user member of 3
>> roles), then this query take more than 20 ms:
>>
>> select * from USER_ROLE_MAPPING where USER_ID='123';
>>
>>
>> 2) MySQL is adding the btree indexes by default even for foreign keys.
>> So the same query like above took less than 1 ms by default.
>>
>>
>> So to improve the time on postgres, the index for USER_ID column in
>> USER_ROLE_MAPPING is needed, however for MySQL adding the index doesn't
>> have any effect as it's already there. In the end, I've explicitly added
>> the indexes into changelog file by default and I can see very good
>> performance for both mysql and postgresql and operations are not
>> dependent on number of users in DB.
>>
>> However in theory, adding the indexes may have bad effect for some
>> databases and slow down the time for create new user etc. I personally
>> don't want to test performance with all supported DBs :) So another
>> approach might be to not explicitly add the indexes and let DBA to do
>> that. I've added the possibility to enable logging some overall
>> statistics from Hibernate, so people can check it by themselves. Let me
>> know if you rather want to go this way and not add indexes by default.
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/61666bf9/attachment.html 

From thomas.raehalme at aitiofinland.com  Tue Apr  5 02:04:20 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Tue, 5 Apr 2016 09:04:20 +0300
Subject: [keycloak-dev] Added DB indexes
In-Reply-To: <CAJgngAf96HbTRx0m+hnY2Hd3+TB8RT5EkKNTM4pxBijte15H-Q@mail.gmail.com>
References: <56FCFB86.6020208@redhat.com>
	<CAK-7U1hGU3WxneDOxWwO7HFyi-6zOgf=V=gg-v6x_Q9DNiME0A@mail.gmail.com>
	<56FD1597.2@redhat.com>
	<CAJgngAf96HbTRx0m+hnY2Hd3+TB8RT5EkKNTM4pxBijte15H-Q@mail.gmail.com>
Message-ID: <CAPyAMoYCXXKhoQrfi_6AuC-XRww3+Okcm68-J1qcQRWBWSUC_Q@mail.gmail.com>

+1 For pre-defined standard indices. The easier the installation process is
to get up and running the better it is for the product.

On Tue, Apr 5, 2016 at 8:58 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> It shouldn't be necessary for a DBA to tweak the scheme to get decent
> performance, we need to make sure the required indexes are there already.
>
> On 31 March 2016 at 14:18, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 31/03/16 13:59, Thomas Darimont wrote:
>>
>> Hello Marek,
>>
>> thanks f?r this interesting hint - our postgres admin recommended the
>> following script to me to find foreig-key index candidates:
>>
>> https://github.com/pgexperts/pgx_scripts/blob/master/indexes/fk_no_index.sql
>>
>> Running that an a fresh keycloak postgres db will return no results...
>> but if you disable the where condition (that checks for usage)
>> at the end you'll get an IMHO useful list of index candidates.
>> I put up a gist with the modified query and results here:
>> <https://gist.github.com/thomasdarimont/992aaad6af704f40fd4483af3d42290e>
>> https://gist.github.com/thomasdarimont/992aaad6af704f40fd4483af3d42290e
>>
>> Thanks Thomas for the interesting script!
>>
>> I've actually didn't add indexes to all foreign keys, but just to those,
>> which are widely used and are supposed to contain big number of records. So
>> especially the tables related to user model. Also I needed to add some
>> indexes to columns, which are not foreign keys (those were needed for both
>> MySQL and PostgreSQL), for example EMAIL of USER_ENTITY table as Keycloak
>> often needs to lookup users by email.
>>
>> Marek
>>
>>
>> Cheers,
>> Thomas
>>
>> 2016-03-31 12:27 GMT+02:00 Marek Posolda <mposolda at redhat.com>:
>>
>>> I've did loads of testing for create/load/delete big number of users
>>> into database and I've send PR for add some additional indexes into
>>> database to improve performance of operations with big number of users
>>> in DB - https://github.com/keycloak/keycloak/pull/2456
>>>
>>> Note that adding DB indexes is tricky as the performance gain (or loss)
>>> might be highly dependent on underlying database. Some example:
>>>
>>> 1) PostgreSQL is adding the indexes by default just for primary keys and
>>> unique constraints. But it doesn't add indexes for foreign keys. So when
>>> you have 50K users in DB and 150K role mappings (each user member of 3
>>> roles), then this query take more than 20 ms:
>>>
>>> select * from USER_ROLE_MAPPING where USER_ID='123';
>>>
>>>
>>> 2) MySQL is adding the btree indexes by default even for foreign keys.
>>> So the same query like above took less than 1 ms by default.
>>>
>>>
>>> So to improve the time on postgres, the index for USER_ID column in
>>> USER_ROLE_MAPPING is needed, however for MySQL adding the index doesn't
>>> have any effect as it's already there. In the end, I've explicitly added
>>> the indexes into changelog file by default and I can see very good
>>> performance for both mysql and postgresql and operations are not
>>> dependent on number of users in DB.
>>>
>>> However in theory, adding the indexes may have bad effect for some
>>> databases and slow down the time for create new user etc. I personally
>>> don't want to test performance with all supported DBs :) So another
>>> approach might be to not explicitly add the indexes and let DBA to do
>>> that. I've added the possibility to enable logging some overall
>>> statistics from Hibernate, so people can check it by themselves. Let me
>>> know if you rather want to go this way and not add indexes by default.
>>>
>>> Marek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> 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/20160405/92ac2ec4/attachment-0001.html 

From sthorger at redhat.com  Tue Apr  5 03:46:17 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Apr 2016 09:46:17 +0200
Subject: [keycloak-dev] Should failure count be reset on successful login
Message-ID: <CAJgngAfrWA_tbt4iX3zTh9ZgH9afUs7L9byW1SLgEZn+KVHr+A@mail.gmail.com>

Currently [1] the failed login attempts are not reset on a successful
login. This could cause a user with bad memory to lock the account over
time. This can be prevented by setting "Failure Reset Time", but is that
sufficient. Should we reset the failed login attempts on successful login?

[1] https://issues.jboss.org/browse/KEYCLOAK-2692
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/b544a360/attachment.html 

From sthorger at redhat.com  Tue Apr  5 04:19:40 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Apr 2016 10:19:40 +0200
Subject: [keycloak-dev] What to do about Java admin client
Message-ID: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>

At least personally I think the admin client needs some TLC. For example
creating a user requires:

        UserRepresentation user = new UserRepresentation();
        user.setUsername("user");

        Response response = keycloak.realm("realm").users().create(user);

        // Retrieve created user id
        String path = response.getLocation().getPath();
        String id = path.substring(path.lastIndexOf('/') + 1);

        // Remember to close the response
        response.close();

        // Set password
        CredentialRepresentation credentials = new
CredentialRepresentation();
        credentials.setType(CredentialRepresentation.PASSWORD);
        credentials.setValue("password");

        keycloak.realm("realm").users().get(id).resetPassword(credentials);

        // Add role
        RoleRepresentation role =
keycloak.realm("realm").roles().get("role").toRepresentation();

keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));

That's pretty rubbish right?

In my opinion a lot of the usability issues is caused by directly exposing
interfaces/proxies from RestEasy Client and it would be much better if we
introduced a wrapper around it.

So my questions are:

1) What do we do with regards to admin client? Do we just wrap what we
have, keep it or create a brand new one from scratch?
2) Is it an issue that we require a specific RestEasy version to use the
admin client? This seems a heavy dependency to me, which could conflict
with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
as it should in theory work with any JAX-RS 2 provider.
3) What do we do with current fixes for admin client? Do we merge to master
and 1.9.x or just merge to master?

At least from my POV the answers are:
1) Create wrappers around interfaces/proxies from RestEasy client and not
expose JAX-RS directly through the API as that should be an implementation
detail
2) Use JAX-RS 2 client
3) Merge fixes to both master and 1.9.x (admin client is not supported in
product for now, so it's less risky)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/b4fd6b2a/attachment.html 

From guus.der.kinderen at gmail.com  Tue Apr  5 06:31:43 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Tue, 5 Apr 2016 12:31:43 +0200
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
Message-ID: <CAMJaV9=UJ2tOXg3jg1MTEQJi_52cFq0FSBDMV9SCJ+ky6Urvxg@mail.gmail.com>

Hi Stian,

First off: I didn't know that Keycloak existed three weeks ago. Much of
what I write might be a result of me being unfamiliar with earlier design
choices. That being said:

Based on the snippet that you provided I'd argue that it is the service,
rather than the admin client, that could/should be improved. When
implementing a (REST) service, it is common to provide a representation as
part of the response to a create (POST) request: the service response
should include the most up-to-date representation of the resource, which
prevents the client from having to reconstruct it (exactly what you're
doing in that snippet), which is tedious, error-prone and lacking the
inclusion of server-generated values. On top of that, if a client needs
multiple requests to recreate a representation, concurrency issues come in
to play. Who's to say that all responses reflect the exact same state,
server sided?

Restructuring the web services could lead to a large change (although
inclusion of representation in responses might be backwards compatible, as
the random sample of services that I checked appear to currently have empty
responses - perhaps the representation could simply 'fit in'). In any case,
timing-wise, such an effort would coincide with the upcoming 2.0
development.

Based on the above, my suggestion would be:
1) Apart from the changes above, there might not be a need to rewrite the
admin client. From my basic use over the last two weeks, I like it's
simplicity. It provides a low-level entry point for people that start with
Keycloak, which is good.
2) I can't say - simply don't have enough experience in this fields. Then
again, in Java, when one says "in theory, it's compatible" it typically
isn't.
3) Apply the changes for the as-is client to 1.9.x, and improve services
(and as a result, the client) in 2.x

Kind regards,

  Guus


On 5 April 2016 at 10:19, Stian Thorgersen <sthorger at redhat.com> wrote:

> At least personally I think the admin client needs some TLC. For example
> creating a user requires:
>
>         UserRepresentation user = new UserRepresentation();
>         user.setUsername("user");
>
>         Response response = keycloak.realm("realm").users().create(user);
>
>         // Retrieve created user id
>         String path = response.getLocation().getPath();
>         String id = path.substring(path.lastIndexOf('/') + 1);
>
>         // Remember to close the response
>         response.close();
>
>         // Set password
>         CredentialRepresentation credentials = new
> CredentialRepresentation();
>         credentials.setType(CredentialRepresentation.PASSWORD);
>         credentials.setValue("password");
>
>         keycloak.realm("realm").users().get(id).resetPassword(credentials);
>
>         // Add role
>         RoleRepresentation role =
> keycloak.realm("realm").roles().get("role").toRepresentation();
>
> keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
>
> That's pretty rubbish right?
>
> In my opinion a lot of the usability issues is caused by directly exposing
> interfaces/proxies from RestEasy Client and it would be much better if we
> introduced a wrapper around it.
>
> So my questions are:
>
> 1) What do we do with regards to admin client? Do we just wrap what we
> have, keep it or create a brand new one from scratch?
> 2) Is it an issue that we require a specific RestEasy version to use the
> admin client? This seems a heavy dependency to me, which could conflict
> with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
> as it should in theory work with any JAX-RS 2 provider.
> 3) What do we do with current fixes for admin client? Do we merge to
> master and 1.9.x or just merge to master?
>
> At least from my POV the answers are:
> 1) Create wrappers around interfaces/proxies from RestEasy client and not
> expose JAX-RS directly through the API as that should be an implementation
> detail
> 2) Use JAX-RS 2 client
> 3) Merge fixes to both master and 1.9.x (admin client is not supported in
> product for now, so it's less risky)
>
> _______________________________________________
> 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/20160405/291f2757/attachment.html 

From mposolda at redhat.com  Tue Apr  5 06:58:10 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 5 Apr 2016 12:58:10 +0200
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
Message-ID: <57039A42.1050100@redhat.com>

On 05/04/16 10:19, Stian Thorgersen wrote:
> At least personally I think the admin client needs some TLC. For 
> example creating a user requires:
>
> UserRepresentation user = new UserRepresentation();
> user.setUsername("user");
>
>         Response response = keycloak.realm("realm").users().create(user);
>
>         // Retrieve created user id
>         String path = response.getLocation().getPath();
>         String id = path.substring(path.lastIndexOf('/') + 1);
>         // Remember to close the response
> response.close();
>
>         // Set password
> CredentialRepresentation credentials = new CredentialRepresentation();
> credentials.setType(CredentialRepresentation.PASSWORD);
> credentials.setValue("password");
> keycloak.realm("realm").users().get(id).resetPassword(credentials);
>         // Add role
> RoleRepresentation role = 
> keycloak.realm("realm").roles().get("role").toRepresentation();
> keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
> That's pretty rubbish right?
>
> In my opinion a lot of the usability issues is caused by directly 
> exposing interfaces/proxies from RestEasy Client and it would be much 
> better if we introduced a wrapper around it.
Yeah, agree that usability is not very great.

However to me personally, the biggest issue is not usability but the 
fact, that admin-client needs to be manually maintained. AFAIK it was 
lots of spent time - especially for Stan and Marko - to have the 
admin-client synced with the latest server. And it seems that earlier or 
later, the issue will be back once we will add more endpoints. We can 
have "policy" that everyone, who is adding new server endpoint, would 
need to update client too (which is usually needed anyway for the test). 
But that still requires some time spend in manually updating code + 
there is some risk that earlier or later will admin-client still become 
outdated...

IMO If we can have admin-client autogenerated, it will be a huge win. I 
am not sure if it's realistic (and seems that it will be even harder to 
accomplish if we use wrapper instead of JAX-RS directly. ) but maybe 
worth to look into it at least?
>
> So my questions are:
>
> 1) What do we do with regards to admin client? Do we just wrap what we 
> have, keep it or create a brand new one from scratch?
> 2) Is it an issue that we require a specific RestEasy version to use 
> the admin client? This seems a heavy dependency to me, which could 
> conflict with other JAX-RS libraries. Using JAX-RS 2 Client would be 
> an improvement as it should in theory work with any JAX-RS 2 provider.
> 3) What do we do with current fixes for admin client? Do we merge to 
> master and 1.9.x or just merge to master?
>
> At least from my POV the answers are:
> 1) Create wrappers around interfaces/proxies from RestEasy client and 
> not expose JAX-RS directly through the API as that should be an 
> implementation detail
+1 for wrappers. And as I mentioned above, look if we can do something 
regarding autogeneration (or at least something else to enforce the 
admin-client won't become outdated again).
> 2) Use JAX-RS 2 client
+1

But it will be good if people have possibility to configure the details 
of underlying Apache HTTP Client (connection pooling, connection/socket 
timeouts, tls etc). If it's possible to achieve it and use JAX-RS 2 
client at the same time, it will be cool. Otherwise if we need to choose 
just one of these, the "configurability" of Apache HTTP client is more 
important IMO.
> 3) Merge fixes to both master and 1.9.x (admin client is not supported 
> in product for now, so it's less risky)
+1

Marek
>
>
> _______________________________________________
> 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/20160405/77a2fdbc/attachment-0001.html 

From mposolda at redhat.com  Tue Apr  5 07:08:00 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 5 Apr 2016 13:08:00 +0200
Subject: [keycloak-dev] Should failure count be reset on successful login
In-Reply-To: <CAJgngAfrWA_tbt4iX3zTh9ZgH9afUs7L9byW1SLgEZn+KVHr+A@mail.gmail.com>
References: <CAJgngAfrWA_tbt4iX3zTh9ZgH9afUs7L9byW1SLgEZn+KVHr+A@mail.gmail.com>
Message-ID: <57039C90.1020107@redhat.com>

On 05/04/16 09:46, Stian Thorgersen wrote:
> Currently [1] the failed login attempts are not reset on a successful 
> login. This could cause a user with bad memory to lock the account 
> over time. This can be prevented by setting "Failure Reset Time", but 
> is that sufficient. Should we reset the failed login attempts on 
> successful login?
I think that yes, I believe that's what most of the web-sites are doing 
as well?

Marek
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-2692
>
>
>
>
> _______________________________________________
> 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/20160405/596c8e66/attachment.html 

From sthorger at redhat.com  Tue Apr  5 07:18:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Apr 2016 13:18:04 +0200
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <CAMJaV9=UJ2tOXg3jg1MTEQJi_52cFq0FSBDMV9SCJ+ky6Urvxg@mail.gmail.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
	<CAMJaV9=UJ2tOXg3jg1MTEQJi_52cFq0FSBDMV9SCJ+ky6Urvxg@mail.gmail.com>
Message-ID: <CAJgngAeHcN50EXs67kZKQHFGfj3ZMrzp_YieLfWeSKbESY3gtA@mail.gmail.com>

On 5 April 2016 at 12:31, Guus der Kinderen <guus.der.kinderen at gmail.com>
wrote:

> Hi Stian,
>
> First off: I didn't know that Keycloak existed three weeks ago. Much of
> what I write might be a result of me being unfamiliar with earlier design
> choices. That being said:
>
> Based on the snippet that you provided I'd argue that it is the service,
> rather than the admin client, that could/should be improved. When
> implementing a (REST) service, it is common to provide a representation as
> part of the response to a create (POST) request: the service response
> should include the most up-to-date representation of the resource, which
> prevents the client from having to reconstruct it (exactly what you're
> doing in that snippet), which is tedious, error-prone and lacking the
> inclusion of server-generated values. On top of that, if a client needs
> multiple requests to recreate a representation, concurrency issues come in
> to play. Who's to say that all responses reflect the exact same state,
> server sided?
>

I did take an extreme example and you're right that it can be improved by
fixing the server side rest endpoints.


>
> Restructuring the web services could lead to a large change (although
> inclusion of representation in responses might be backwards compatible, as
> the random sample of services that I checked appear to currently have empty
> responses - perhaps the representation could simply 'fit in'). In any case,
> timing-wise, such an effort would coincide with the upcoming 2.0
> development.
>

We have been discussing to introduce a version 2.0 of the rest api, we'd
still keep version 1 for backwards compatibility for a while at least.


>
> Based on the above, my suggestion would be:
> 1) Apart from the changes above, there might not be a need to rewrite the
> admin client. From my basic use over the last two weeks, I like it's
> simplicity. It provides a low-level entry point for people that start with
> Keycloak, which is good.
>

Maybe you're right and the client will be simpler to use once we improve
the server side


> 2) I can't say - simply don't have enough experience in this fields. Then
> again, in Java, when one says "in theory, it's compatible" it typically
> isn't.
>

;)


> 3) Apply the changes for the as-is client to 1.9.x, and improve services
> (and as a result, the client) in 2.x
>
> Kind regards,
>
>   Guus
>
>
> On 5 April 2016 at 10:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> At least personally I think the admin client needs some TLC. For example
>> creating a user requires:
>>
>>         UserRepresentation user = new UserRepresentation();
>>         user.setUsername("user");
>>
>>         Response response = keycloak.realm("realm").users().create(user);
>>
>>         // Retrieve created user id
>>         String path = response.getLocation().getPath();
>>         String id = path.substring(path.lastIndexOf('/') + 1);
>>
>>         // Remember to close the response
>>         response.close();
>>
>>         // Set password
>>         CredentialRepresentation credentials = new
>> CredentialRepresentation();
>>         credentials.setType(CredentialRepresentation.PASSWORD);
>>         credentials.setValue("password");
>>
>>
>> keycloak.realm("realm").users().get(id).resetPassword(credentials);
>>
>>         // Add role
>>         RoleRepresentation role =
>> keycloak.realm("realm").roles().get("role").toRepresentation();
>>
>> keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
>>
>> That's pretty rubbish right?
>>
>> In my opinion a lot of the usability issues is caused by directly
>> exposing interfaces/proxies from RestEasy Client and it would be much
>> better if we introduced a wrapper around it.
>>
>> So my questions are:
>>
>> 1) What do we do with regards to admin client? Do we just wrap what we
>> have, keep it or create a brand new one from scratch?
>> 2) Is it an issue that we require a specific RestEasy version to use the
>> admin client? This seems a heavy dependency to me, which could conflict
>> with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
>> as it should in theory work with any JAX-RS 2 provider.
>> 3) What do we do with current fixes for admin client? Do we merge to
>> master and 1.9.x or just merge to master?
>>
>> At least from my POV the answers are:
>> 1) Create wrappers around interfaces/proxies from RestEasy client and not
>> expose JAX-RS directly through the API as that should be an implementation
>> detail
>> 2) Use JAX-RS 2 client
>> 3) Merge fixes to both master and 1.9.x (admin client is not supported in
>> product for now, so it's less risky)
>>
>> _______________________________________________
>> 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/20160405/81397430/attachment.html 

From sthorger at redhat.com  Tue Apr  5 07:22:00 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Apr 2016 13:22:00 +0200
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <57039A42.1050100@redhat.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
	<57039A42.1050100@redhat.com>
Message-ID: <CAJgngAe_sGcQnbj_HTrFNFuwO7GgwkkKhNw255o3MqQpR2K_rA@mail.gmail.com>

On 5 April 2016 at 12:58, Marek Posolda <mposolda at redhat.com> wrote:

> On 05/04/16 10:19, Stian Thorgersen wrote:
>
> At least personally I think the admin client needs some TLC. For example
> creating a user requires:
>
>         UserRepresentation user = new UserRepresentation();
>         user.setUsername("user");
>
>         Response response = keycloak.realm("realm").users().create(user);
>
>         // Retrieve created user id
>         String path = response.getLocation().getPath();
>         String id = path.substring(path.lastIndexOf('/') + 1);
>
>         // Remember to close the response
>         response.close();
>
>         // Set password
>         CredentialRepresentation credentials = new
> CredentialRepresentation();
>         credentials.setType(CredentialRepresentation.PASSWORD);
>         credentials.setValue("password");
>
>         keycloak.realm("realm").users().get(id).resetPassword(credentials);
>
>         // Add role
>         RoleRepresentation role =
> keycloak.realm("realm").roles().get("role").toRepresentation();
>
> keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
>
> That's pretty rubbish right?
>
> In my opinion a lot of the usability issues is caused by directly exposing
> interfaces/proxies from RestEasy Client and it would be much better if we
> introduced a wrapper around it.
>
> Yeah, agree that usability is not very great.
>
> However to me personally, the biggest issue is not usability but the fact,
> that admin-client needs to be manually maintained. AFAIK it was lots of
> spent time - especially for Stan and Marko - to have the admin-client
> synced with the latest server. And it seems that earlier or later, the
> issue will be back once we will add more endpoints. We can have "policy"
> that everyone, who is adding new server endpoint, would need to update
> client too (which is usually needed anyway for the test). But that still
> requires some time spend in manually updating code + there is some risk
> that earlier or later will admin-client still become outdated...
>
> IMO If we can have admin-client autogenerated, it will be a huge win. I am
> not sure if it's realistic (and seems that it will be even harder to
> accomplish if we use wrapper instead of JAX-RS directly. ) but maybe worth
> to look into it at least?
>

I don't think auto-generating is realistic. Nor do I think it will be a
particularly big issue going forward. If anyone touches the admin endpoints
they WILL update the admin client as well as add tests for it, end of ;)


>
> So my questions are:
>
> 1) What do we do with regards to admin client? Do we just wrap what we
> have, keep it or create a brand new one from scratch?
> 2) Is it an issue that we require a specific RestEasy version to use the
> admin client? This seems a heavy dependency to me, which could conflict
> with other JAX-RS libraries. Using JAX-RS 2 Client would be an improvement
> as it should in theory work with any JAX-RS 2 provider.
> 3) What do we do with current fixes for admin client? Do we merge to
> master and 1.9.x or just merge to master?
>
> At least from my POV the answers are:
> 1) Create wrappers around interfaces/proxies from RestEasy client and not
> expose JAX-RS directly through the API as that should be an implementation
> detail
>
> +1 for wrappers. And as I mentioned above, look if we can do something
> regarding autogeneration (or at least something else to enforce the
> admin-client won't become outdated again).
>

API's, user interfaces, etc.. can NOT be auto-generated if you want to have
anything remotely usable


>
> 2) Use JAX-RS 2 client
>
> +1
>
> But it will be good if people have possibility to configure the details of
> underlying Apache HTTP Client (connection pooling, connection/socket
> timeouts, tls etc). If it's possible to achieve it and use JAX-RS 2 client
> at the same time, it will be cool. Otherwise if we need to choose just one
> of these, the "configurability" of Apache HTTP client is more important IMO.
>

Sticking with RestEasy Client makes the assumption that all users use other
JBoss projects. We know that's not true as Tomcat, Jetty and Spring
adapters all have a lot of use. IMO we should either convert to JAX-RS 2
client or use Apache HTTP client directly (I'm not to keen on that though).

> 3) Merge fixes to both master and 1.9.x (admin client is not supported in
> product for now, so it's less risky)
>
> +1
>
> Marek
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/dce77890/attachment-0001.html 

From mposolda at redhat.com  Tue Apr  5 07:47:04 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 5 Apr 2016 13:47:04 +0200
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <CAJgngAe_sGcQnbj_HTrFNFuwO7GgwkkKhNw255o3MqQpR2K_rA@mail.gmail.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
	<57039A42.1050100@redhat.com>
	<CAJgngAe_sGcQnbj_HTrFNFuwO7GgwkkKhNw255o3MqQpR2K_rA@mail.gmail.com>
Message-ID: <5703A5B8.30209@redhat.com>

On 05/04/16 13:22, Stian Thorgersen wrote:
>
>
> On 5 April 2016 at 12:58, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 05/04/16 10:19, Stian Thorgersen wrote:
>>     At least personally I think the admin client needs some TLC. For
>>     example creating a user requires:
>>
>>     UserRepresentation user = new UserRepresentation();
>>     user.setUsername("user");
>>
>>     Response response = keycloak.realm("realm").users().create(user);
>>
>>     // Retrieve created user id
>>     String path = response.getLocation().getPath();
>>     String id = path.substring(path.lastIndexOf('/') + 1);
>>     // Remember to close the response
>>     response.close();
>>
>>     // Set password
>>     CredentialRepresentation credentials = new
>>     CredentialRepresentation();
>>     credentials.setType(CredentialRepresentation.PASSWORD);
>>     credentials.setValue("password");
>>     keycloak.realm("realm").users().get(id).resetPassword(credentials);
>>     // Add role
>>     RoleRepresentation role =
>>     keycloak.realm("realm").roles().get("role").toRepresentation();
>>     keycloak.realm("realm").users().get(id).roles().realmLevel().add(Collections.singletonList(role));
>>     That's pretty rubbish right?
>>
>>     In my opinion a lot of the usability issues is caused by directly
>>     exposing interfaces/proxies from RestEasy Client and it would be
>>     much better if we introduced a wrapper around it.
>     Yeah, agree that usability is not very great.
>
>     However to me personally, the biggest issue is not usability but
>     the fact, that admin-client needs to be manually maintained. AFAIK
>     it was lots of spent time - especially for Stan and Marko - to
>     have the admin-client synced with the latest server. And it seems
>     that earlier or later, the issue will be back once we will add
>     more endpoints. We can have "policy" that everyone, who is adding
>     new server endpoint, would need to update client too (which is
>     usually needed anyway for the test). But that still requires some
>     time spend in manually updating code + there is some risk that
>     earlier or later will admin-client still become outdated...
>
>     IMO If we can have admin-client autogenerated, it will be a huge
>     win. I am not sure if it's realistic (and seems that it will be
>     even harder to accomplish if we use wrapper instead of JAX-RS
>     directly. ) but maybe worth to look into it at least?
>
>
> I don't think auto-generating is realistic. Nor do I think it will be 
> a particularly big issue going forward. If anyone touches the admin 
> endpoints they WILL update the admin client as well as add tests for 
> it, end of ;)
>
>>
>>     So my questions are:
>>
>>     1) What do we do with regards to admin client? Do we just wrap
>>     what we have, keep it or create a brand new one from scratch?
>>     2) Is it an issue that we require a specific RestEasy version to
>>     use the admin client? This seems a heavy dependency to me, which
>>     could conflict with other JAX-RS libraries. Using JAX-RS 2 Client
>>     would be an improvement as it should in theory work with any
>>     JAX-RS 2 provider.
>>     3) What do we do with current fixes for admin client? Do we merge
>>     to master and 1.9.x or just merge to master?
>>
>>     At least from my POV the answers are:
>>     1) Create wrappers around interfaces/proxies from RestEasy client
>>     and not expose JAX-RS directly through the API as that should be
>>     an implementation detail
>     +1 for wrappers. And as I mentioned above, look if we can do
>     something regarding autogeneration (or at least something else to
>     enforce the admin-client won't become outdated again).
>
>
> API's, user interfaces, etc.. can NOT be auto-generated if you want to 
> have anything remotely usable
>
>
>>     2) Use JAX-RS 2 client
>     +1
>
>     But it will be good if people have possibility to configure the
>     details of underlying Apache HTTP Client (connection pooling,
>     connection/socket timeouts, tls etc). If it's possible to achieve
>     it and use JAX-RS 2 client at the same time, it will be cool.
>     Otherwise if we need to choose just one of these, the
>     "configurability" of Apache HTTP client is more important IMO.
>
>
> Sticking with RestEasy Client makes the assumption that all users use 
> other JBoss projects. We know that's not true as Tomcat, Jetty and 
> Spring adapters all have a lot of use. IMO we should either convert to 
> JAX-RS 2 client or use Apache HTTP client directly (I'm not to keen on 
> that though).
At least we may just have possibility to inject underlying 
javax.ws.rs.client.Client during creation of admin-client. So if someone 
is on resteasy and wants to tweak Apache HTTP Client, he can use 
RestEasy API to build client by himself and inject it. If he's using 
some other library, he would need to use it's API to build client (and 
possibly configure connection pooling etc in library specific way).

Marek
>
>>     3) Merge fixes to both master and 1.9.x (admin client is not
>>     supported in product for now, so it's less risky)
>     +1
>
>     Marek
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From bburke at redhat.com  Tue Apr  5 08:19:15 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 5 Apr 2016 08:19:15 -0400
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <5703A5B8.30209@redhat.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
	<57039A42.1050100@redhat.com>
	<CAJgngAe_sGcQnbj_HTrFNFuwO7GgwkkKhNw255o3MqQpR2K_rA@mail.gmail.com>
	<5703A5B8.30209@redhat.com>
Message-ID: <5703AD43.5050702@redhat.com>



On 4/5/2016 7:47 AM, Marek Posolda wrote:
>
>>>     2) Use JAX-RS 2 client
>>     +1
>>
>>     But it will be good if people have possibility to configure the
>>     details of underlying Apache HTTP Client (connection pooling,
>>     connection/socket timeouts, tls etc). If it's possible to achieve
>>     it and use JAX-RS 2 client at the same time, it will be cool.
>>     Otherwise if we need to choose just one of these, the
>>     "configurability" of Apache HTTP client is more important IMO.
>>
>>
>> Sticking with RestEasy Client makes the assumption that all users use 
>> other JBoss projects. We know that's not true as Tomcat, Jetty and 
>> Spring adapters all have a lot of use. IMO we should either convert 
>> to JAX-RS 2 client or use Apache HTTP client directly (I'm not to 
>> keen on that though).
> At least we may just have possibility to inject underlying 
> javax.ws.rs.client.Client during creation of admin-client. So if 
> someone is on resteasy and wants to tweak Apache HTTP Client, he can 
> use RestEasy API to build client by himself and inject it. If he's 
> using some other library, he would need to use it's API to build 
> client (and possibly configure connection pooling etc in library 
> specific way).
>
  If you're using Tomcat, Spring or whatever, anything JBoss is evil and 
they can't co-exist?  That's ridiculous.  You're really going to stub 
out every single piece of the REST api and/or write your own tool?  No....

We revise the rest interface.  Either use Resteasy, or they can write 
their own clients.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/9365367a/attachment.html 

From sthorger at redhat.com  Tue Apr  5 08:32:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Apr 2016 14:32:21 +0200
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <5703AD43.5050702@redhat.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
	<57039A42.1050100@redhat.com>
	<CAJgngAe_sGcQnbj_HTrFNFuwO7GgwkkKhNw255o3MqQpR2K_rA@mail.gmail.com>
	<5703A5B8.30209@redhat.com> <5703AD43.5050702@redhat.com>
Message-ID: <CAJgngAdzzDAN4Fb1KboPegLExOgfoow4ZoitxO7UfOZ8v3bb+Q@mail.gmail.com>

On 5 April 2016 at 14:19, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 4/5/2016 7:47 AM, Marek Posolda wrote:
>
>
> 2) Use JAX-RS 2 client
>>
>> +1
>>
>> But it will be good if people have possibility to configure the details
>> of underlying Apache HTTP Client (connection pooling, connection/socket
>> timeouts, tls etc). If it's possible to achieve it and use JAX-RS 2 client
>> at the same time, it will be cool. Otherwise if we need to choose just one
>> of these, the "configurability" of Apache HTTP client is more important IMO.
>>
>
> Sticking with RestEasy Client makes the assumption that all users use
> other JBoss projects. We know that's not true as Tomcat, Jetty and Spring
> adapters all have a lot of use. IMO we should either convert to JAX-RS 2
> client or use Apache HTTP client directly (I'm not to keen on that though).
>
> At least we may just have possibility to inject underlying javax.ws.rs.client.Client
> during creation of admin-client. So if someone is on resteasy and wants to
> tweak Apache HTTP Client, he can use RestEasy API to build client by
> himself and inject it. If he's using some other library, he would need to
> use it's API to build client (and possibly configure connection pooling etc
> in library specific way).
>
>  If you're using Tomcat, Spring or whatever, anything JBoss is evil and
> they can't co-exist?  That's ridiculous.  You're really going to stub out
> every single piece of the REST api and/or write your own tool?  No....
>

What's wrong with JAX-RS 2.0?


>
> We revise the rest interface.  Either use Resteasy, or they can write
> their own clients.
>

What are you saying here exactly?


>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160405/5d25a653/attachment-0001.html 

From bburke at redhat.com  Tue Apr  5 08:34:47 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 5 Apr 2016 08:34:47 -0400
Subject: [keycloak-dev] DB changes now to get ready for 2.0?
Message-ID: <5703B0E7.10405@redhat.com>

In 2.0 we want to refactor and merge the User Federation and Model APIs 
for users.  All references to users, groups, and roles would turn into 
longer 255 char URIs.  This would require DB schema change right now to. 
Remove foreign key constraints and expand reference column to 255 
characters on:

* UserRoleMappingEntity
* UserGroupMembershipEntity
* GroupRoleMappingEntity
* UserConsentEntity
* UserConsentRoleEntity
* UserRequiredActionEntity
* UserAttributeEntity
* GroupAttributeEntity

Do we want to make this change now?  I have no idea what effect this 
would have on migration of removing secondary keys and expanding column 
size.  Would robably have to drop and recreate indexes too. Do we delay 
this until this is speced out?  Or do we make the change now?

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


From bburke at redhat.com  Tue Apr  5 08:36:57 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 5 Apr 2016 08:36:57 -0400
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <CAJgngAdzzDAN4Fb1KboPegLExOgfoow4ZoitxO7UfOZ8v3bb+Q@mail.gmail.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
	<57039A42.1050100@redhat.com>
	<CAJgngAe_sGcQnbj_HTrFNFuwO7GgwkkKhNw255o3MqQpR2K_rA@mail.gmail.com>
	<5703A5B8.30209@redhat.com> <5703AD43.5050702@redhat.com>
	<CAJgngAdzzDAN4Fb1KboPegLExOgfoow4ZoitxO7UfOZ8v3bb+Q@mail.gmail.com>
Message-ID: <5703B169.8020503@redhat.com>



On 4/5/2016 8:32 AM, Stian Thorgersen wrote:
>
>
> On 5 April 2016 at 14:19, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 4/5/2016 7:47 AM, Marek Posolda wrote:
>>
>>>>         2) Use JAX-RS 2 client
>>>         +1
>>>
>>>         But it will be good if people have possibility to configure
>>>         the details of underlying Apache HTTP Client (connection
>>>         pooling, connection/socket timeouts, tls etc). If it's
>>>         possible to achieve it and use JAX-RS 2 client at the same
>>>         time, it will be cool. Otherwise if we need to choose just
>>>         one of these, the "configurability" of Apache HTTP client is
>>>         more important IMO.
>>>
>>>
>>>     Sticking with RestEasy Client makes the assumption that all
>>>     users use other JBoss projects. We know that's not true as
>>>     Tomcat, Jetty and Spring adapters all have a lot of use. IMO we
>>>     should either convert to JAX-RS 2 client or use Apache HTTP
>>>     client directly (I'm not to keen on that though).
>>     At least we may just have possibility to inject underlying
>>     javax.ws.rs <http://javax.ws.rs>.client.Client during creation of
>>     admin-client. So if someone is on resteasy and wants to tweak
>>     Apache HTTP Client, he can use RestEasy API to build client by
>>     himself and inject it. If he's using some other library, he would
>>     need to use it's API to build client (and possibly configure
>>     connection pooling etc in library specific way).
>>
>      If you're using Tomcat, Spring or whatever, anything JBoss is
>     evil and they can't co-exist?  That's ridiculous.  You're really
>     going to stub out every single piece of the REST api and/or write
>     your own tool?  No....
>
>
> What's wrong with JAX-RS 2.0?
The proxy thing is Resteasy specific.  Its not in the spec.

>
>     We revise the rest interface.  Either use Resteasy, or they can
>     write their own clients.
>
>
> What are you saying here exactly?

That we use Resteasy to create the admin client.  If somebody doesn't 
want to have a dependency on Resteasy then they are on their own.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/9906912f/attachment.html 

From sthorger at redhat.com  Tue Apr  5 08:45:17 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Apr 2016 14:45:17 +0200
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <5703B169.8020503@redhat.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
	<57039A42.1050100@redhat.com>
	<CAJgngAe_sGcQnbj_HTrFNFuwO7GgwkkKhNw255o3MqQpR2K_rA@mail.gmail.com>
	<5703A5B8.30209@redhat.com> <5703AD43.5050702@redhat.com>
	<CAJgngAdzzDAN4Fb1KboPegLExOgfoow4ZoitxO7UfOZ8v3bb+Q@mail.gmail.com>
	<5703B169.8020503@redhat.com>
Message-ID: <CAJgngAdmBBW2P-2cg3qx_u8L_cT2Sxa5_uZoFSm_Q92ux7ut2A@mail.gmail.com>

On 5 April 2016 at 14:36, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 4/5/2016 8:32 AM, Stian Thorgersen wrote:
>
>
>
> On 5 April 2016 at 14:19, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 4/5/2016 7:47 AM, Marek Posolda wrote:
>>
>>
>> 2) Use JAX-RS 2 client
>>>
>>> +1
>>>
>>> But it will be good if people have possibility to configure the details
>>> of underlying Apache HTTP Client (connection pooling, connection/socket
>>> timeouts, tls etc). If it's possible to achieve it and use JAX-RS 2 client
>>> at the same time, it will be cool. Otherwise if we need to choose just one
>>> of these, the "configurability" of Apache HTTP client is more important IMO.
>>>
>>
>> Sticking with RestEasy Client makes the assumption that all users use
>> other JBoss projects. We know that's not true as Tomcat, Jetty and Spring
>> adapters all have a lot of use. IMO we should either convert to JAX-RS 2
>> client or use Apache HTTP client directly (I'm not to keen on that though).
>>
>> At least we may just have possibility to inject underlying javax.ws.rs.client.Client
>> during creation of admin-client. So if someone is on resteasy and wants to
>> tweak Apache HTTP Client, he can use RestEasy API to build client by
>> himself and inject it. If he's using some other library, he would need to
>> use it's API to build client (and possibly configure connection pooling etc
>> in library specific way).
>>
>>  If you're using Tomcat, Spring or whatever, anything JBoss is evil and
>> they can't co-exist?  That's ridiculous.  You're really going to stub out
>> every single piece of the REST api and/or write your own tool?  No....
>>
>
We're already stubbing out everything due to having to create the
interfaces. I've never been convinced about exposing RestEasy client
interfaces/proxies directly as the usability is not very good IMO.
Especially around error handling.


>
> What's wrong with JAX-RS 2.0?
>
>
> The proxy thing is Resteasy specific.  Its not in the spec.
>

What's this then
http://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/client/ClientBuilder.html
?


>
>
>
>> We revise the rest interface.  Either use Resteasy, or they can write
>> their own clients.
>>
>
> What are you saying here exactly?
>
>
> That we use Resteasy to create the admin client.  If somebody doesn't want
> to have a dependency on Resteasy then they are on their own.
>

>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/4579b436/attachment.html 

From bburke at redhat.com  Tue Apr  5 08:54:54 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 5 Apr 2016 08:54:54 -0400
Subject: [keycloak-dev] What to do about Java admin client
In-Reply-To: <CAJgngAdmBBW2P-2cg3qx_u8L_cT2Sxa5_uZoFSm_Q92ux7ut2A@mail.gmail.com>
References: <CAJgngAffX_-FQ8YEnYQFoP2O1wHB6JZY_4Ox75P2188Ddwetbg@mail.gmail.com>
	<57039A42.1050100@redhat.com>
	<CAJgngAe_sGcQnbj_HTrFNFuwO7GgwkkKhNw255o3MqQpR2K_rA@mail.gmail.com>
	<5703A5B8.30209@redhat.com> <5703AD43.5050702@redhat.com>
	<CAJgngAdzzDAN4Fb1KboPegLExOgfoow4ZoitxO7UfOZ8v3bb+Q@mail.gmail.com>
	<5703B169.8020503@redhat.com>
	<CAJgngAdmBBW2P-2cg3qx_u8L_cT2Sxa5_uZoFSm_Q92ux7ut2A@mail.gmail.com>
Message-ID: <5703B59E.4020605@redhat.com>



On 4/5/2016 8:45 AM, Stian Thorgersen wrote:
>
>
> On 5 April 2016 at 14:36, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 4/5/2016 8:32 AM, Stian Thorgersen wrote:
>>
>>
>>     On 5 April 2016 at 14:19, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>         On 4/5/2016 7:47 AM, Marek Posolda wrote:
>>>
>>>>>             2) Use JAX-RS 2 client
>>>>             +1
>>>>
>>>>             But it will be good if people have possibility to
>>>>             configure the details of underlying Apache HTTP Client
>>>>             (connection pooling, connection/socket timeouts, tls
>>>>             etc). If it's possible to achieve it and use JAX-RS 2
>>>>             client at the same time, it will be cool. Otherwise if
>>>>             we need to choose just one of these, the
>>>>             "configurability" of Apache HTTP client is more
>>>>             important IMO.
>>>>
>>>>
>>>>         Sticking with RestEasy Client makes the assumption that all
>>>>         users use other JBoss projects. We know that's not true as
>>>>         Tomcat, Jetty and Spring adapters all have a lot of use.
>>>>         IMO we should either convert to JAX-RS 2 client or use
>>>>         Apache HTTP client directly (I'm not to keen on that though).
>>>         At least we may just have possibility to inject underlying
>>>         javax.ws.rs <http://javax.ws.rs>.client.Client during
>>>         creation of admin-client. So if someone is on resteasy and
>>>         wants to tweak Apache HTTP Client, he can use RestEasy API
>>>         to build client by himself and inject it. If he's using some
>>>         other library, he would need to use it's API to build client
>>>         (and possibly configure connection pooling etc in library
>>>         specific way).
>>>
>>          If you're using Tomcat, Spring or whatever, anything JBoss
>>         is evil and they can't co-exist?  That's ridiculous. You're
>>         really going to stub out every single piece of the REST api
>>         and/or write your own tool?  No....
>>
>
> We're already stubbing out everything due to having to create the 
> interfaces. I've never been convinced about exposing RestEasy client 
> interfaces/proxies directly as the usability is not very good IMO. 
> Especially around error handling.
>
>>
>>     What's wrong with JAX-RS 2.0?
>     The proxy thing is Resteasy specific.  Its not in the spec.
>
>
> What's this then 
> http://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/client/ClientBuilder.html?

You cannot create a proxy through JAX-RS client api.  It doesn't exist.  
ClientBuilder creates the base client (similar to HttpClient in 
Apache).  Even that is not comprehensive enough and you still need to 
use implementation specific APIs.

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

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

From guus.der.kinderen at gmail.com  Tue Apr  5 09:39:31 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Tue, 5 Apr 2016 15:39:31 +0200
Subject: [keycloak-dev] Should failure count be reset on successful login
In-Reply-To: <57039C90.1020107@redhat.com>
References: <CAJgngAfrWA_tbt4iX3zTh9ZgH9afUs7L9byW1SLgEZn+KVHr+A@mail.gmail.com>
	<57039C90.1020107@redhat.com>
Message-ID: <CAMJaV9kE+tccM97W9XMe53pirSJFJkC_MkAiqiWi7zGFjKjUUg@mail.gmail.com>

When an attacker can trick a valid user into logging in (over and over and
over) again, resetting that counter upon successful authentication could
expose an attack vector: An attacker brute forces, while coercing the
legitimate user to reset the failed-attempt count. It is somewhat
far-fetched, but not unimaginable. I'd err on the side of caution.
Combining a counter with a time-out value will prevent this completely.

 - Guus

On 5 April 2016 at 13:08, Marek Posolda <mposolda at redhat.com> wrote:

> On 05/04/16 09:46, Stian Thorgersen wrote:
>
> Currently [1] the failed login attempts are not reset on a successful
> login. This could cause a user with bad memory to lock the account over
> time. This can be prevented by setting "Failure Reset Time", but is that
> sufficient. Should we reset the failed login attempts on successful login?
>
> I think that yes, I believe that's what most of the web-sites are doing as
> well?
>
> Marek
>
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-2692
>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/f7a7ec89/attachment.html 

From bburke at redhat.com  Tue Apr  5 09:57:31 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 5 Apr 2016 09:57:31 -0400
Subject: [keycloak-dev] Should failure count be reset on successful login
In-Reply-To: <CAMJaV9kE+tccM97W9XMe53pirSJFJkC_MkAiqiWi7zGFjKjUUg@mail.gmail.com>
References: <CAJgngAfrWA_tbt4iX3zTh9ZgH9afUs7L9byW1SLgEZn+KVHr+A@mail.gmail.com>
	<57039C90.1020107@redhat.com>
	<CAMJaV9kE+tccM97W9XMe53pirSJFJkC_MkAiqiWi7zGFjKjUUg@mail.gmail.com>
Message-ID: <5703C44B.4060403@redhat.com>

I agree.  IIRC, there already is a reset timer that you can configure.  
Can I close this?

On 4/5/2016 9:39 AM, Guus der Kinderen wrote:
> When an attacker can trick a valid user into logging in (over and over 
> and over) again, resetting that counter upon successful authentication 
> could expose an attack vector: An attacker brute forces, while 
> coercing the legitimate user to reset the failed-attempt count. It is 
> somewhat far-fetched, but not unimaginable. I'd err on the side of 
> caution. Combining a counter with a time-out value will prevent this 
> completely.
>
>  - Guus
>
> On 5 April 2016 at 13:08, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 05/04/16 09:46, Stian Thorgersen wrote:
>>     Currently [1] the failed login attempts are not reset on a
>>     successful login. This could cause a user with bad memory to lock
>>     the account over time. This can be prevented by setting "Failure
>>     Reset Time", but is that sufficient. Should we reset the failed
>>     login attempts on successful login?
>     I think that yes, I believe that's what most of the web-sites are
>     doing as well?
>
>     Marek
>>
>>     [1] https://issues.jboss.org/browse/KEYCLOAK-2692
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/96a85f4c/attachment.html 

From sthorger at redhat.com  Tue Apr  5 10:02:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Apr 2016 16:02:21 +0200
Subject: [keycloak-dev] Should failure count be reset on successful login
In-Reply-To: <5703C44B.4060403@redhat.com>
References: <CAJgngAfrWA_tbt4iX3zTh9ZgH9afUs7L9byW1SLgEZn+KVHr+A@mail.gmail.com>
	<57039C90.1020107@redhat.com>
	<CAMJaV9kE+tccM97W9XMe53pirSJFJkC_MkAiqiWi7zGFjKjUUg@mail.gmail.com>
	<5703C44B.4060403@redhat.com>
Message-ID: <CAJgngAeX+UzdHYZoL3LEygM8ZQc+DdT1SOwQynOLPJnoiNh2OA@mail.gmail.com>

Rejected

On 5 April 2016 at 15:57, Bill Burke <bburke at redhat.com> wrote:

> I agree.  IIRC, there already is a reset timer that you can configure.
> Can I close this?
>
>
> On 4/5/2016 9:39 AM, Guus der Kinderen wrote:
>
> When an attacker can trick a valid user into logging in (over and over and
> over) again, resetting that counter upon successful authentication could
> expose an attack vector: An attacker brute forces, while coercing the
> legitimate user to reset the failed-attempt count. It is somewhat
> far-fetched, but not unimaginable. I'd err on the side of caution.
> Combining a counter with a time-out value will prevent this completely.
>
>  - Guus
>
> On 5 April 2016 at 13:08, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 05/04/16 09:46, Stian Thorgersen wrote:
>>
>> Currently [1] the failed login attempts are not reset on a successful
>> login. This could cause a user with bad memory to lock the account over
>> time. This can be prevented by setting "Failure Reset Time", but is that
>> sufficient. Should we reset the failed login attempts on successful login?
>>
>> I think that yes, I believe that's what most of the web-sites are doing
>> as well?
>>
>> Marek
>>
>>
>> [1] https://issues.jboss.org/browse/KEYCLOAK-2692
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160405/856707e5/attachment.html 

From 00hf11 at gmail.com  Tue Apr  5 12:36:48 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Tue, 5 Apr 2016 13:36:48 -0300
Subject: [keycloak-dev] KEYCLOAK-2638 - Access to keycloak login page from
	nodejs app fails.
Message-ID: <CABv=XZVab+cESk3WZfnWrhdGFa1aixK9-ydy5RkP7QpCDo7RJw@mail.gmail.com>

Hi folks,

I'm going to take a look into this :
https://issues.jboss.org/browse/KEYCLOAK-2638
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160405/d170ab96/attachment.html 

From mposolda at redhat.com  Tue Apr  5 12:42:32 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 5 Apr 2016 18:42:32 +0200
Subject: [keycloak-dev] DB changes now to get ready for 2.0?
In-Reply-To: <5703B0E7.10405@redhat.com>
References: <5703B0E7.10405@redhat.com>
Message-ID: <5703EAF8.5090205@redhat.com>

Not sure, I am slightly to do it later. The migration will be pain 
anyway, as we already need to support migrating from older Keycloak 
community versions.

Doing it later once we have specs has advantage, that we will know what 
exactly we want to do. Doing it now has risk, that we will still need 
later to do some other changes in schema. So we will have to do the 
migration pain for 2 times (now and later too).

Marek

On 05/04/16 14:34, Bill Burke wrote:
> In 2.0 we want to refactor and merge the User Federation and Model APIs
> for users.  All references to users, groups, and roles would turn into
> longer 255 char URIs.  This would require DB schema change right now to.
> Remove foreign key constraints and expand reference column to 255
> characters on:
>
> * UserRoleMappingEntity
> * UserGroupMembershipEntity
> * GroupRoleMappingEntity
> * UserConsentEntity
> * UserConsentRoleEntity
> * UserRequiredActionEntity
> * UserAttributeEntity
> * GroupAttributeEntity
>
> Do we want to make this change now?  I have no idea what effect this
> would have on migration of removing secondary keys and expanding column
> size.  Would robably have to drop and recreate indexes too. Do we delay
> this until this is speced out?  Or do we make the change now?
>


From marc.savy at redhat.com  Tue Apr  5 14:04:24 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 5 Apr 2016 19:04:24 +0100
Subject: [keycloak-dev] Conceptual Questions
In-Reply-To: <CAJgngAfDSn0v7Hw8QVmLoAq3MtskdvGcVrjywT-Q1Xpf+pZC9w@mail.gmail.com>
References: <56E9DFB2.6070802@redhat.com>
	<CAJgngAex--XycSmcX82YSLAjLpr6p789GvW2i340PZSccW-j7g@mail.gmail.com>
	<56FD91F5.4030700@redhat.com>
	<CAJgngAfDSn0v7Hw8QVmLoAq3MtskdvGcVrjywT-Q1Xpf+pZC9w@mail.gmail.com>
Message-ID: <CAA7j38LTJRJGtZct2_c0RCXjNgV5CT96kE5EHg4Atw+74EoeCg@mail.gmail.com>

Will this be recorded? I'd also very much like to hear/see a deeper
exploration of these concepts as some of the areas mentioned by John
are a bit hazy to me, too.



On 4 April 2016 at 06:43, Stian Thorgersen <sthorger at redhat.com> wrote:
> +1 To conference call.
>
> Looks like we have one on Thursday is that suitable or do we need a separate
> session?
>
>
>
> On 31 March 2016 at 23:09, John Dennis <jdennis at redhat.com> wrote:
>>
>> On 03/22/2016 03:40 AM, Stian Thorgersen wrote:
>>>
>>> That's a very long list of questions. Have you read through our
>>> documentation? I would hope it at least answers some of these questions.
>>> If not then breaking this list into smaller emails would make it easier
>>> to answer. Answering all these questions in one go is a fairly time
>>> consuming job.
>>
>>
>> I'm not looking to waste anyone's time. I've read all the documentation,
>> watched all the keycloak videos, read the relevant RFC's and browsed the
>> Keycloak source code. These are the questions I was left with after having
>> done my homework :-)
>>
>> I recognize the Keycloak team is at a very busy juncture at this point in
>> time. Perhaps the best course forward would be a recordable conference call
>> the details of which are probably best handled off-list.
>>
>>
>> --
>> John
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Wed Apr  6 02:08:40 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Apr 2016 08:08:40 +0200
Subject: [keycloak-dev] KEYCLOAK-2638 - Access to keycloak login page
 from nodejs app fails.
In-Reply-To: <CABv=XZVab+cESk3WZfnWrhdGFa1aixK9-ydy5RkP7QpCDo7RJw@mail.gmail.com>
References: <CABv=XZVab+cESk3WZfnWrhdGFa1aixK9-ydy5RkP7QpCDo7RJw@mail.gmail.com>
Message-ID: <CAJgngAdi6=x1kACnMsCdc9oj9=h-WgnJyZ0Q5K54gp+=eAvEvQ@mail.gmail.com>

Merged, thanks

On 5 April 2016 at 18:36, Helio Frota <00hf11 at gmail.com> wrote:

> Hi folks,
>
> I'm going to take a look into this :
> https://issues.jboss.org/browse/KEYCLOAK-2638
>
>
>
> _______________________________________________
> 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/20160406/c75cf452/attachment.html 

From sthorger at redhat.com  Wed Apr  6 03:09:46 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Apr 2016 09:09:46 +0200
Subject: [keycloak-dev] Modules in server marked as private
Message-ID: <CAJgngAe5px=pLr_GBiGveWY-bTCF5HiUxZ3N9BzHrGe8=auFLw@mail.gmail.com>

All modules in the server are now marked as private. This caused some
problems due to Keycloak itself using these modules. The fix for that was
to introduce a dependencies module which adds the services module (which in
turn adds most other things). This cause another issue as the
persistence.xml wasn't found. I couldn't find a way to have the jpa module
private as well as loading persistence.xml from it using standard
Persistence.createEntityManagerFactory. The solution to that was found in
the PR we have to allow adding custom entities, which uses a different
mechanism to load the EntityManagerFactory that allows specifying the
ClassLoader.

Changes in
https://github.com/keycloak/keycloak/pull/2511/files#diff-ecd3344fed68cc1f51c41c09711b7c60R43
if anyone is interested.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160406/cc3a430a/attachment.html 

From jayapriya.atheesan at gmail.com  Wed Apr  6 03:43:55 2016
From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN)
Date: Wed, 6 Apr 2016 13:13:55 +0530
Subject: [keycloak-dev] Access-Control-Allow-Origin' header is present on
	the requested resource. Origin is therefore not allowed access.
Message-ID: <5704be42.6537420a.4ee4e.6b8b@mx.google.com>

Hi,

 

We are trying to get access token from keycloak after logging onto the
giggzo realm created using angular js.

 

But we are getting the below exception

 

XMLHttpRequest cannot load
https://api.giggso.com:8444/auth/realms/giggzo/account. No
'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://release.projectstatus.in' is therefore not allowed access.
The response had HTTP status code 403.

dashboardCtrl.js:26 Failed to load profile

 

I have tried adding web origin - * in both security-admin-console client as
well as account. Even then, it is not going through.

 

Kindly help me in resolving the same.

 

Thanks,

Jayapriya Atheesan

 

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

From sthorger at redhat.com  Wed Apr  6 05:47:52 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Apr 2016 11:47:52 +0200
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAPyAMobupSFA2+YHZhdcmDMiyB+bz0OzR=wLr437j2BR86o1SA@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
	<CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
	<CAPyAMoYOLvRGmuffG+s6pdE2jAAC0bKHMPwh=mhCjHqJywpmXA@mail.gmail.com>
	<CAJgngAe_jCkgwwULQw791cCL+YZr_QuSuwsR0NsdzFQswnE=hA@mail.gmail.com>
	<CAPyAMobupSFA2+YHZhdcmDMiyB+bz0OzR=wLr437j2BR86o1SA@mail.gmail.com>
Message-ID: <CAJgngAeLAQQqBO36DJ_nT1oXfTdDPp2HYJCxyBvujJUCOdn-bg@mail.gmail.com>

Problem with a built-in JMS event listener provider is that it should send
messages to an external JMS server. Keycloak itself should not act as a JMS
server. Further, there's no standard way to connect to JMS providers, so
best we could do is one that connects to WildFly/EAP and make it easy for
users to extend it to connect to different providers (maybe an
getDestination() method).

At the moment I've got no spare time to help out in detail with Arquillian
part, although I can answer questions over email if that's enough. For the
Arquillian part I'd suggest starting an embedded Archimedes server in the
test.

On 4 April 2016 at 13:44, Thomas Raehalme <thomas.raehalme at aitiofinland.com>
wrote:

> It would probably be a good idea although I think this JMS publishing is
> such a basic feature that it should be part of the core package.
>
> If you have a chance to help me get started with the Arquillian part, I'm
> happy to send the PR. I should have time to work on this again within the
> next week or so.
>
> Best regards,
> Thomas
>
>
> On Mon, Apr 4, 2016 at 12:26 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> I wonder if we should have a Keycloak extensions repository where we
>> could place things like this rather than adding directly to master.
>>
>> On 31 March 2016 at 20:18, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>>> Hi,
>>>
>>> On Thu, Mar 31, 2016 at 4:38 PM, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> would you mind sharing your keycloak configuration with a JMS
>>>> resource-adapter?
>>>>
>>>
>>> Here are the changes I made to standalone/configuration/standalone.xml:
>>>
>>> 1. Added the following extension under /server/extensions:
>>>
>>> <extension module="org.wildfly.extension.messaging-activemq"/>
>>>
>>> 2. Added the following subsystem under /server/profile:
>>>
>>> <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
>>>     <server name="default">
>>>         <security enabled="false" /> <!-- I didn't need to use security
>>> as everything was localhost -->
>>>         <remote-acceptor name="netty" socket-binding="messaging"/>
>>>         <remote-connector name="netty" socket-binding="messaging"/>
>>>         <in-vm-acceptor name="in-vm" server-id="0"/>
>>>         <in-vm-connector name="in-vm" server-id="0"/>
>>>         <pooled-connection-factory name="activemq-ra"
>>>                     transaction="xa" connectors="in-vm"
>>>                     entries="java:/ConnectionFactory java:/JmsXA
>>> java:jboss/DefaultJMSConnectionFactory"/>
>>>         <jms-topic name="KeycloakEvents" entries="jms/KeycloakEvents
>>> java:jboss/exported/jms/KeycloakEvents" />
>>>     </server>
>>> </subsystem>
>>>
>>> 3. Added the following socket-binding under /server/socket-binding-group:
>>>
>>> <socket-binding name="messaging" port="61616"/>
>>>
>>> This enabled my external process to listen to the JMS topic.
>>>
>>> I attached a full example to this message. The changes have been marked
>>> with <!-- keycloak-events-jms -->.
>>>
>>> Did you manage to configure a new resource-adapter via jboss-cli?
>>>>
>>>
>>> No, I haven't used jboss-cli but modified the configuration file
>>> directly.
>>>
>>> My implementation of KEYCLOAK-2302 can be found at Github:
>>> https://github.com/raehalme/keycloak/tree/KEYCLOAK-2302.
>>>
>>> I have not sent a PR as I have yet to complete the Arquillian
>>> integration tests requested by Stian. Other work has kept me busy and I
>>> haven't had a chance to even rebase against 1.9.x.
>>>
>>> Best regards,
>>> Thomas
>>>
>>>
>>> _______________________________________________
>>> 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/20160406/631af642/attachment-0001.html 

From thomas.raehalme at aitiofinland.com  Wed Apr  6 05:52:28 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 6 Apr 2016 12:52:28 +0300
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAJgngAeLAQQqBO36DJ_nT1oXfTdDPp2HYJCxyBvujJUCOdn-bg@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
	<CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
	<CAPyAMoYOLvRGmuffG+s6pdE2jAAC0bKHMPwh=mhCjHqJywpmXA@mail.gmail.com>
	<CAJgngAe_jCkgwwULQw791cCL+YZr_QuSuwsR0NsdzFQswnE=hA@mail.gmail.com>
	<CAPyAMobupSFA2+YHZhdcmDMiyB+bz0OzR=wLr437j2BR86o1SA@mail.gmail.com>
	<CAJgngAeLAQQqBO36DJ_nT1oXfTdDPp2HYJCxyBvujJUCOdn-bg@mail.gmail.com>
Message-ID: <CAPyAMoaO+Hr6xFdDJwzP9i4K0VP-maVBWHNg9Oqu38S-Kg03aA@mail.gmail.com>

On Wed, Apr 6, 2016 at 12:47 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Problem with a built-in JMS event listener provider is that it should send
> messages to an external JMS server. Keycloak itself should not act as a JMS
> server. Further, there's no standard way to connect to JMS providers, so
> best we could do is one that connects to WildFly/EAP and make it easy for
> users to extend it to connect to different providers (maybe an
> getDestination() method).
>

I understand that the configuration cannot (and should not) be enabled by
default, but it would be great if it was enough for the user to just modify
the Wildfly/Keycloak configuration instead of having to add modules, jars
and whatever to the installation. Examples of the configuration can be
provided separately.

At the moment I've got no spare time to help out in detail with Arquillian
> part, although I can answer questions over email if that's enough. For the
> Arquillian part I'd suggest starting an embedded Archimedes server in the
> test.
>

That'll do just fine, thanks! I'll get in touch as soon as I have time to
work on this (and encounter a problem).

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160406/e9de6ec5/attachment.html 

From sthorger at redhat.com  Wed Apr  6 05:57:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Apr 2016 11:57:57 +0200
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAPyAMoaO+Hr6xFdDJwzP9i4K0VP-maVBWHNg9Oqu38S-Kg03aA@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
	<CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
	<CAPyAMoYOLvRGmuffG+s6pdE2jAAC0bKHMPwh=mhCjHqJywpmXA@mail.gmail.com>
	<CAJgngAe_jCkgwwULQw791cCL+YZr_QuSuwsR0NsdzFQswnE=hA@mail.gmail.com>
	<CAPyAMobupSFA2+YHZhdcmDMiyB+bz0OzR=wLr437j2BR86o1SA@mail.gmail.com>
	<CAJgngAeLAQQqBO36DJ_nT1oXfTdDPp2HYJCxyBvujJUCOdn-bg@mail.gmail.com>
	<CAPyAMoaO+Hr6xFdDJwzP9i4K0VP-maVBWHNg9Oqu38S-Kg03aA@mail.gmail.com>
Message-ID: <CAJgngAfoG_M_FXAaunTVdaQvYQ9xj0r5JfscQ4ys63ucrCA0+g@mail.gmail.com>

On 6 April 2016 at 11:52, Thomas Raehalme <thomas.raehalme at aitiofinland.com>
wrote:

>
> On Wed, Apr 6, 2016 at 12:47 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Problem with a built-in JMS event listener provider is that it should
>> send messages to an external JMS server. Keycloak itself should not act as
>> a JMS server. Further, there's no standard way to connect to JMS providers,
>> so best we could do is one that connects to WildFly/EAP and make it easy
>> for users to extend it to connect to different providers (maybe an
>> getDestination() method).
>>
>
> I understand that the configuration cannot (and should not) be enabled by
> default, but it would be great if it was enough for the user to just modify
> the Wildfly/Keycloak configuration instead of having to add modules, jars
> and whatever to the installation. Examples of the configuration can be
> provided separately.
>

User would at the very least be required to have a separate WildFly
installation to use as a JMS server. We will not document how to make
Keycloak (underlying WildFly) itself act as JMS server. However, I'm happy
to include a provider that can connect to the external JMS server, allow
extending to connect to other providers. Documentation only needs to cover
how to configure it to connect to an external JMS server (on WildFly/EAP).
It doesn't need to cover setup of the JMS server itself, but can link to
relevant WildFly documentation.


>
> At the moment I've got no spare time to help out in detail with Arquillian
>> part, although I can answer questions over email if that's enough. For the
>> Arquillian part I'd suggest starting an embedded Archimedes server in the
>> test.
>>
>
> That'll do just fine, thanks! I'll get in touch as soon as I have time to
> work on this (and encounter a problem).
>
> Best regards,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160406/16a0d861/attachment.html 

From sthorger at redhat.com  Wed Apr  6 06:04:53 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Apr 2016 12:04:53 +0200
Subject: [keycloak-dev] Better error message for login timeouts
Message-ID: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>

I suggest we change the error message when a login times out or a code is
not valid to:
"This page is no longer valid, please retry login from the application" and
also include a link to the application if available.

I think that's more user friendly than "You took to long" and "We're
sorry...".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160406/84b331ba/attachment.html 

From thomas.raehalme at aitiofinland.com  Wed Apr  6 06:07:49 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 6 Apr 2016 13:07:49 +0300
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAJgngAfoG_M_FXAaunTVdaQvYQ9xj0r5JfscQ4ys63ucrCA0+g@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
	<CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
	<CAPyAMoYOLvRGmuffG+s6pdE2jAAC0bKHMPwh=mhCjHqJywpmXA@mail.gmail.com>
	<CAJgngAe_jCkgwwULQw791cCL+YZr_QuSuwsR0NsdzFQswnE=hA@mail.gmail.com>
	<CAPyAMobupSFA2+YHZhdcmDMiyB+bz0OzR=wLr437j2BR86o1SA@mail.gmail.com>
	<CAJgngAeLAQQqBO36DJ_nT1oXfTdDPp2HYJCxyBvujJUCOdn-bg@mail.gmail.com>
	<CAPyAMoaO+Hr6xFdDJwzP9i4K0VP-maVBWHNg9Oqu38S-Kg03aA@mail.gmail.com>
	<CAJgngAfoG_M_FXAaunTVdaQvYQ9xj0r5JfscQ4ys63ucrCA0+g@mail.gmail.com>
Message-ID: <CAPyAMoYCqa6WhDTqYFrT8suyALjoPU_weQ4ZWB_ggLKpUW=Ggw@mail.gmail.com>

On Wed, Apr 6, 2016 at 12:57 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> On 6 April 2016 at 11:52, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>>
>> On Wed, Apr 6, 2016 at 12:47 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Problem with a built-in JMS event listener provider is that it should
>>> send messages to an external JMS server. Keycloak itself should not act as
>>> a JMS server. Further, there's no standard way to connect to JMS providers,
>>> so best we could do is one that connects to WildFly/EAP and make it easy
>>> for users to extend it to connect to different providers (maybe an
>>> getDestination() method).
>>>
>>
>> I understand that the configuration cannot (and should not) be enabled by
>> default, but it would be great if it was enough for the user to just modify
>> the Wildfly/Keycloak configuration instead of having to add modules, jars
>> and whatever to the installation. Examples of the configuration can be
>> provided separately.
>>
>
> User would at the very least be required to have a separate WildFly
> installation to use as a JMS server. We will not document how to make
> Keycloak (underlying WildFly) itself act as JMS server. However, I'm happy
> to include a provider that can connect to the external JMS server, allow
> extending to connect to other providers. Documentation only needs to cover
> how to configure it to connect to an external JMS server (on WildFly/EAP).
> It doesn't need to cover setup of the JMS server itself, but can link to
> relevant WildFly documentation.
>

Including the provider is what I meant. No need to document on how to do
some external stuff.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160406/38f73083/attachment.html 

From guus.der.kinderen at gmail.com  Wed Apr  6 06:11:34 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Wed, 6 Apr 2016 12:11:34 +0200
Subject: [keycloak-dev] Better error message for login timeouts
In-Reply-To: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
References: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
Message-ID: <CAMJaV9nUX23Z=1Z5pURobnJ6Wr0w1we8dmto+W4zcgowB0ct0A@mail.gmail.com>

"Not long valid" is somewhat vague. To avoid confusion, I'd try to be as
clear as possible about what's going on and what should be done to resolve
the problem. At the same time, do not refer to the user ('you') directly,
to have a friendlier tone-of-voice:

"A timeout has occurred. Please reload this page."



On 6 April 2016 at 12:04, Stian Thorgersen <sthorger at redhat.com> wrote:

> I suggest we change the error message when a login times out or a code is
> not valid to:
> "This page is no longer valid, please retry login from the application"
> and also include a link to the application if available.
>
> I think that's more user friendly than "You took to long" and "We're
> sorry...".
>
> _______________________________________________
> 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/20160406/6656bf93/attachment-0001.html 

From sthorger at redhat.com  Wed Apr  6 06:21:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Apr 2016 12:21:19 +0200
Subject: [keycloak-dev] Better error message for login timeouts
In-Reply-To: <CAMJaV9nUX23Z=1Z5pURobnJ6Wr0w1we8dmto+W4zcgowB0ct0A@mail.gmail.com>
References: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
	<CAMJaV9nUX23Z=1Z5pURobnJ6Wr0w1we8dmto+W4zcgowB0ct0A@mail.gmail.com>
Message-ID: <CAJgngAc7Qt__TzOJZGSV0jA+xFCaEC54yJsMefEXNBN_u4Q6GQ@mail.gmail.com>

The page is no longer valid, that's really what's going on ;)

There's mainly three scenarios when this happens:

* User clicks link twice in an email (for example reset password)
* User clicks link in email after it has expired
* User spends to long on the login form(s)

Problem is that we don't know exactly which of the above is the problem as
the session details may be lost. So I believe "This page is no longer
valid" is generic and still gives the user an idea of what's happened.
Refreshing the page is not going to help as the page is no longer valid
(login details are either lost due to timeout, or login has already
happened), so to resolve the problem the user has to "try login again from
the application". We can replace "the application" with the name of the
client if we now it and also make it clickable if the client has a baseurl
set.


On 6 April 2016 at 12:11, Guus der Kinderen <guus.der.kinderen at gmail.com>
wrote:

> "Not long valid" is somewhat vague. To avoid confusion, I'd try to be as
> clear as possible about what's going on and what should be done to resolve
> the problem. At the same time, do not refer to the user ('you') directly,
> to have a friendlier tone-of-voice:
>
> "A timeout has occurred. Please reload this page."
>
>
>
> On 6 April 2016 at 12:04, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> I suggest we change the error message when a login times out or a code is
>> not valid to:
>> "This page is no longer valid, please retry login from the application"
>> and also include a link to the application if available.
>>
>> I think that's more user friendly than "You took to long" and "We're
>> sorry...".
>>
>> _______________________________________________
>> 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/20160406/8de2edeb/attachment.html 

From juraci at kroehling.de  Wed Apr  6 06:22:56 2016
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 6 Apr 2016 12:22:56 +0200
Subject: [keycloak-dev] Better error message for login timeouts
In-Reply-To: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
References: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
Message-ID: <5704E380.1040003@kroehling.de>

On 06.04.2016 12:04, Stian Thorgersen wrote:
> I suggest we change the error message when a login times out or a code
> is not valid to:
> "This page is no longer valid, please retry login from the application"
> and also include a link to the application if available.
>
> I think that's more user friendly than "You took to long" and "We're
> sorry...".

While I, as an user, would probably understand what went wrong with a 
message like "You took too long" and would accept my fate, I would have 
no idea what I did wrong to deserve a "This page is no longer valid".

Perhaps phrasing it in a way that is both informative and friendly?

- Juca.

From guus.der.kinderen at gmail.com  Wed Apr  6 06:22:57 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Wed, 6 Apr 2016 12:22:57 +0200
Subject: [keycloak-dev] Better error message for login timeouts
In-Reply-To: <CAJgngAc7Qt__TzOJZGSV0jA+xFCaEC54yJsMefEXNBN_u4Q6GQ@mail.gmail.com>
References: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
	<CAMJaV9nUX23Z=1Z5pURobnJ6Wr0w1we8dmto+W4zcgowB0ct0A@mail.gmail.com>
	<CAJgngAc7Qt__TzOJZGSV0jA+xFCaEC54yJsMefEXNBN_u4Q6GQ@mail.gmail.com>
Message-ID: <CAMJaV9=LFCmd=VERgskSTx0hNTk6=EjM31MQ+-TiLAjO97ZOYw@mail.gmail.com>

Ah, I was only aware of that last scenario. Serves me right for butting in
on things I know next to nothing about. ;)

On 6 April 2016 at 12:21, Stian Thorgersen <sthorger at redhat.com> wrote:

> The page is no longer valid, that's really what's going on ;)
>
> There's mainly three scenarios when this happens:
>
> * User clicks link twice in an email (for example reset password)
> * User clicks link in email after it has expired
> * User spends to long on the login form(s)
>
> Problem is that we don't know exactly which of the above is the problem as
> the session details may be lost. So I believe "This page is no longer
> valid" is generic and still gives the user an idea of what's happened.
> Refreshing the page is not going to help as the page is no longer valid
> (login details are either lost due to timeout, or login has already
> happened), so to resolve the problem the user has to "try login again from
> the application". We can replace "the application" with the name of the
> client if we now it and also make it clickable if the client has a baseurl
> set.
>
>
> On 6 April 2016 at 12:11, Guus der Kinderen <guus.der.kinderen at gmail.com>
> wrote:
>
>> "Not long valid" is somewhat vague. To avoid confusion, I'd try to be as
>> clear as possible about what's going on and what should be done to resolve
>> the problem. At the same time, do not refer to the user ('you') directly,
>> to have a friendlier tone-of-voice:
>>
>> "A timeout has occurred. Please reload this page."
>>
>>
>>
>> On 6 April 2016 at 12:04, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>>> I suggest we change the error message when a login times out or a code
>>> is not valid to:
>>> "This page is no longer valid, please retry login from the application"
>>> and also include a link to the application if available.
>>>
>>> I think that's more user friendly than "You took to long" and "We're
>>> sorry...".
>>>
>>> _______________________________________________
>>> 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/20160406/2c42dff8/attachment.html 

From sthorger at redhat.com  Wed Apr  6 06:47:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Apr 2016 12:47:24 +0200
Subject: [keycloak-dev] Better error message for login timeouts
In-Reply-To: <5704E380.1040003@kroehling.de>
References: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
	<5704E380.1040003@kroehling.de>
Message-ID: <CAJgngAfRP7xF7Cs_E+Md32pBwbQRYYG51fQAEnxv9PariJ_uBw@mail.gmail.com>

Suggestions are welcome ;)

That's the best I can come up with

On 6 April 2016 at 12:22, Juraci Paix?o Kr?hling <juraci at kroehling.de>
wrote:

> On 06.04.2016 12:04, Stian Thorgersen wrote:
> > I suggest we change the error message when a login times out or a code
> > is not valid to:
> > "This page is no longer valid, please retry login from the application"
> > and also include a link to the application if available.
> >
> > I think that's more user friendly than "You took to long" and "We're
> > sorry...".
>
> While I, as an user, would probably understand what went wrong with a
> message like "You took too long" and would accept my fate, I would have
> no idea what I did wrong to deserve a "This page is no longer valid".
>
> Perhaps phrasing it in a way that is both informative and friendly?
>
> - Juca.
> _______________________________________________
> 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/20160406/4229fc69/attachment.html 

From guus.der.kinderen at gmail.com  Wed Apr  6 06:57:59 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Wed, 6 Apr 2016 12:57:59 +0200
Subject: [keycloak-dev] Better error message for login timeouts
In-Reply-To: <CAJgngAfRP7xF7Cs_E+Md32pBwbQRYYG51fQAEnxv9PariJ_uBw@mail.gmail.com>
References: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
	<5704E380.1040003@kroehling.de>
	<CAJgngAfRP7xF7Cs_E+Md32pBwbQRYYG51fQAEnxv9PariJ_uBw@mail.gmail.com>
Message-ID: <CAMJaV9nKtb2LQxiTJDTuGOAMuvm4CH091=mXBy5XOOB03ghZNg@mail.gmail.com>

Is it an option to have distinct messages for each scenario?

"This page is no longer valid (the link you used to get to this page can
only be used once)."
"The link you used to get to this page has expired."
"This page has timed-out. Please reload the page and try again."


On 6 April 2016 at 12:47, Stian Thorgersen <sthorger at redhat.com> wrote:

> Suggestions are welcome ;)
>
> That's the best I can come up with
>
> On 6 April 2016 at 12:22, Juraci Paix?o Kr?hling <juraci at kroehling.de>
> wrote:
>
>> On 06.04.2016 12:04, Stian Thorgersen wrote:
>> > I suggest we change the error message when a login times out or a code
>> > is not valid to:
>> > "This page is no longer valid, please retry login from the application"
>> > and also include a link to the application if available.
>> >
>> > I think that's more user friendly than "You took to long" and "We're
>> > sorry...".
>>
>> While I, as an user, would probably understand what went wrong with a
>> message like "You took too long" and would accept my fate, I would have
>> no idea what I did wrong to deserve a "This page is no longer valid".
>>
>> Perhaps phrasing it in a way that is both informative and friendly?
>>
>> - Juca.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160406/90527e2e/attachment-0001.html 

From juraci at kroehling.de  Wed Apr  6 07:09:38 2016
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 6 Apr 2016 13:09:38 +0200
Subject: [keycloak-dev] Better error message for login timeouts
In-Reply-To: <CAJgngAfRP7xF7Cs_E+Md32pBwbQRYYG51fQAEnxv9PariJ_uBw@mail.gmail.com>
References: <CAJgngAepd0SKbhC4nLTkKgCHGr2+FeY-Y87gyC69s=7Lqecr9Q@mail.gmail.com>
	<5704E380.1040003@kroehling.de>
	<CAJgngAfRP7xF7Cs_E+Md32pBwbQRYYG51fQAEnxv9PariJ_uBw@mail.gmail.com>
Message-ID: <5704EE72.308@kroehling.de>

On 06.04.2016 12:47, Stian Thorgersen wrote:
> Suggestions are welcome ;)

Taking the scenarios from your other email, an initial suggestion could be:

<<EOD

Unfortunately, we cannot securely log you in at this time. Please, go 
back to the application and try to login again.

Reasons for this might include:

* You didn't promptly login when reaching the login page;
* The link you used to reach the login page has already been used;
* The link you received to reach the login page has expired.

EOD




From lkrzyzan at redhat.com  Thu Apr  7 07:47:56 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Thu, 7 Apr 2016 13:47:56 +0200
Subject: [keycloak-dev] Correct behavior on KC login/reg pages when user is
	already logged in
Message-ID: <FB9AA4B7-D905-49DE-8F9B-1A3ACC314C34@redhat.com>

Hi,
when user successfully logs in (either after registration or login) then hitting back button shows KC page (login/registration) again.

This looks to be a bug to me because user is logged in and should be allowed to do only logout. No login or registration.

I tried how google.com <http://google.com/> behaves and when you successfully logs in then hitting back button is handled correctly - their sso realize that you?re logged in and then user is redirected to requested page. No login page.

I think KC should follow same behavior.

Jira for login flow: https://issues.jboss.org/browse/KEYCLOAK-2768 <https://issues.jboss.org/browse/KEYCLOAK-2768>
Jira for reg. flow: https://issues.jboss.org/browse/KEYCLOAK-2740 <https://issues.jboss.org/browse/KEYCLOAK-2740>

Thanks,

Libor Krzy?anek
Principal Software Engineer
Red Hat Developers | Engineering

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

From sthorger at redhat.com  Thu Apr  7 09:31:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 7 Apr 2016 15:31:07 +0200
Subject: [keycloak-dev] Correct behavior on KC login/reg pages when user
 is already logged in
In-Reply-To: <FB9AA4B7-D905-49DE-8F9B-1A3ACC314C34@redhat.com>
References: <FB9AA4B7-D905-49DE-8F9B-1A3ACC314C34@redhat.com>
Message-ID: <CAJgngAdP-LPgTE+gmqXYxphJMJcRF65KkGo9dbFM1mOoJm3Gdg@mail.gmail.com>

I agree it should either show a page is no longer valid message or redirect
back to origin as you're suggesting. The latter is the best, but we need to
be able to identify that's actually what should be done. I tried with
Google and it actually didn't work for me, it showed me the password page
again.

On 7 April 2016 at 13:47, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:

> Hi,
> when user successfully logs in (either after registration or login) then
> hitting back button shows KC page (login/registration) again.
>
> This looks to be a bug to me because user is logged in and should be
> allowed to do only logout. No login or registration.
>
> I tried how google.com behaves and when you successfully logs in then
> hitting back button is handled correctly - their sso realize that you?re
> logged in and then user is redirected to requested page. No login page.
>
> I think KC should follow same behavior.
>
> Jira for login flow: https://issues.jboss.org/browse/KEYCLOAK-2768
> Jira for reg. flow: https://issues.jboss.org/browse/KEYCLOAK-2740
>
> Thanks,
>
> Libor Krzy?anek
> Principal Software Engineer
> Red Hat Developers | Engineering
>
>
> _______________________________________________
> 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/20160407/f8848677/attachment.html 

From cpitman at redhat.com  Thu Apr  7 15:42:59 2016
From: cpitman at redhat.com (Chris Pitman)
Date: Thu, 7 Apr 2016 15:42:59 -0400 (EDT)
Subject: [keycloak-dev] Adding ProxyPeerAddressHandler to Keycloak Proxy
In-Reply-To: <1159685209.48883608.1460057612990.JavaMail.zimbra@redhat.com>
Message-ID: <1105411934.48887544.1460058179471.JavaMail.zimbra@redhat.com>

Hey everyone,

I've run into an issue where the Keycloak Proxy is building an incorrect redirect_url when it is behind an SSL terminating reverse-proxy/load balancer. The redirect_url ends up with an "http" scheme, even with a x-forwarded-proto of "https". I'm new to undertow, but it looks like what needs to change is adding a configuration like "behind-reverse-proxy" that when true adds the ProxyPeerAddressHandler.

First, does that sound correct? And any objection to me adding this capability?

Chris Pitman
Architect, Red Hat Consulting


From srossillo at smartling.com  Thu Apr  7 16:56:29 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Thu, 7 Apr 2016 16:56:29 -0400
Subject: [keycloak-dev] [keycloak-user] Logouts / how to disable
	keycloak "user session" cache?
In-Reply-To: <CAK-7U1iqT77oK_AF_eNHf+gm49c=Ezv2qSP9SyevxRRdVSZS7g@mail.gmail.com>
References: <EA3467C5-7A77-4526-888F-6AEF92CFDF6C@datek.no>
	<CAJgngAdF95op7hb-tYrXOLj6t=Luf2M2Z3CXzF_v+0FD49D-kw@mail.gmail.com>
	<CAK-7U1iqT77oK_AF_eNHf+gm49c=Ezv2qSP9SyevxRRdVSZS7g@mail.gmail.com>
Message-ID: <8E6D7F6B-C214-454F-BA0C-F8ECF4ECC894@smartling.com>

Hi!

We completed the final steps to getting this working on Amazon AWS with Docker using Keycloak 1.9.x. Since we already have a database, we used JDBC_PING not to add S3 as yet another dependency.

The changes are here[0] for now. Would Keycloak devs be interested in adding a running Keycloak on AWS section or another sample docker image?

There are 3 steps / files:

1. configureCache.xsl sets up Infinispan correctly
2. start.sh - Uses Amazon APIs via HTTP to get the correct instance IP information
3. 30_docker_ports.config - if using Docker, this shell script runs on deploy to expose the cluster port to the EC2 interface. Needed with Beanstalk, maybe not with ECS

[0]: https://gist.github.com/foo4u/ad2fa7251ac5b4d4fd318f668f50f7ac

Best,
Scott

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Apr 7, 2016, at 6:44 AM, Thomas Darimont <thomas.darimont at googlemail.com> wrote:
> 
> Hello,
> 
> have a look at this thread: http://lists.jboss.org/pipermail/keycloak-user/2016-February/004935.html <http://lists.jboss.org/pipermail/keycloak-user/2016-February/004935.html>
> 
> Cheers,
> Thomas
> 
> 2016-04-07 12:40 GMT+02:00 Stian Thorgersen <sthorger at redhat.com <mailto:sthorger at redhat.com>>:
> It is not currently possible to run multiple nodes without clustering. However, it's possible to configure JGroups to work on AWS. I can't remember the configuration required though, but if you search the user mailing list you'll find instructions or google for JGroups and AWS.
> 
> On 7 April 2016 at 10:22, Christian Schwarz <christian at datek.no <mailto:christian at datek.no>> wrote:
> Hi!
> 
> I'm trying to setup a keycloak cluster on AWS, which does not support UDP multicast. IP addresses of the nodes are also not known in advance (I'm using docker-cloud), so Infinispan/JGroups ("keycloak-ha-posgres" docker image) for user session replication will not work (seems that it requires either UDP multicast or IP addresses known in advance).
> 
> The main problem I have is that logout is not working propertly. I only get logged out from one of the two keycloak nodes.
> 
> I have tried to disable the user cache (by setting userCache.default.enabled = false) and to disable infinispan (by using ?keycloak-postgres? docker image), but to no avail. The ?other? keycloak node still thinks that the user is logged in, it?s not refreshing the user session from the database even if user cache and infinispan cluster cache is disbled.
> 
> => Is there a possibility of using the database as a synchronization point between keycloak nodes? (i.e. each node always checks logout status in the database)
> Or is there another way of getting a keycloak cluster up and running on AWS when IP addresses are not known in advance?
> 
> I hope there is a way? :)
> 
> Kind regards,
> Christian
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

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

From bburke at redhat.com  Thu Apr  7 20:28:54 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 7 Apr 2016 20:28:54 -0400
Subject: [keycloak-dev] please dont' touch adapters or adapter dist
Message-ID: <5706FB46.1000206@redhat.com>

I'm doing a lot of re-org in adapters and adapters dist to add like 6 
different modules.  Please don't touch anything there right now as I 
don't want to deal with merge conflicts as I'm touching a ton of files.

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


From lkrzyzan at redhat.com  Fri Apr  8 03:59:27 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Fri, 8 Apr 2016 09:59:27 +0200
Subject: [keycloak-dev] Correct behavior on KC login/reg pages when user
	is already logged in
In-Reply-To: <CAJgngAdP-LPgTE+gmqXYxphJMJcRF65KkGo9dbFM1mOoJm3Gdg@mail.gmail.com>
References: <FB9AA4B7-D905-49DE-8F9B-1A3ACC314C34@redhat.com>
	<CAJgngAdP-LPgTE+gmqXYxphJMJcRF65KkGo9dbFM1mOoJm3Gdg@mail.gmail.com>
Message-ID: <5CA8AF32-E005-4156-BFD3-A9D18AD119AA@redhat.com>

Thanks Stian for getting my point.

Here is screencast how google works for me: https://dl.dropboxusercontent.com/u/40512422/devel/keycloak/google-login-back-button.mov <https://dl.dropboxusercontent.com/u/40512422/devel/keycloak/google-login-back-button.mov>

Let me describe these things from really ?end user? perspective.

If I?m trying to feel like a really ?end-user? the only thing that Login Server is responsible for is provide me a way (registration or login) to give me access to let?s call it ?secured content".
I don?t care about login server. I care about the secured content.
If I?m successfully logged in and SSO session exists I should not see any ?no longer valid? message because it?s not true. I?m logged in so everything is OK and I didn?t make any mistake. I successfully logs in and should get the ?secured content?.


In case the login server would give me ?page is no longer valid? brings to my mind something like ?I was logged out? or ?I did something wrong? or ?I need to do something again like do login again".


Thanks,

Libor Krzy?anek
Principal Software Engineer
Red Hat Developers | Engineering

> On Apr 7, 2016, at 3:31 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> I agree it should either show a page is no longer valid message or redirect back to origin as you're suggesting. The latter is the best, but we need to be able to identify that's actually what should be done. I tried with Google and it actually didn't work for me, it showed me the password page again.
> 
> On 7 April 2016 at 13:47, Libor Krzyzanek <lkrzyzan at redhat.com <mailto:lkrzyzan at redhat.com>> wrote:
> Hi,
> when user successfully logs in (either after registration or login) then hitting back button shows KC page (login/registration) again.
> 
> This looks to be a bug to me because user is logged in and should be allowed to do only logout. No login or registration.
> 
> I tried how google.com <http://google.com/> behaves and when you successfully logs in then hitting back button is handled correctly - their sso realize that you?re logged in and then user is redirected to requested page. No login page.
> 
> I think KC should follow same behavior.
> 
> Jira for login flow: https://issues.jboss.org/browse/KEYCLOAK-2768 <https://issues.jboss.org/browse/KEYCLOAK-2768>
> Jira for reg. flow: https://issues.jboss.org/browse/KEYCLOAK-2740 <https://issues.jboss.org/browse/KEYCLOAK-2740>
> 
> Thanks,
> 
> Libor Krzy?anek
> Principal Software Engineer
> Red Hat Developers | Engineering
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> 

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

From duarteetraud at gmail.com  Sat Apr  9 08:45:36 2016
From: duarteetraud at gmail.com (Duarte)
Date: Sat, 9 Apr 2016 13:45:36 +0100
Subject: [keycloak-dev] Attribute-based Access Control
Message-ID: <CALvqGZDStXX=UH5Q4Lkhwp8E9d+=QRtLjQEpw2G+SrpFWegPgA@mail.gmail.com>

Hi,

My name is Duarte, and this is the first post on this dev-list.

My question is regarding Attribute-based Access Control. Is there any
usable feature for Attribute based decision for resource access? Or do I
have to make my own?

Basically what I want to do is a PEP (Policy Enforcement Point) and a PDP
(Policy Decision Point) on Keycloak with external attributes (Federated).

e.g: User has attribute of X can only access files A<->B and User with
attribute Y can only access B<->L.

Thank you.

--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160409/49a6a31f/attachment.html 

From sthorger at redhat.com  Mon Apr 11 00:55:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 11 Apr 2016 06:55:25 +0200
Subject: [keycloak-dev] Correct behavior on KC login/reg pages when user
 is already logged in
In-Reply-To: <5CA8AF32-E005-4156-BFD3-A9D18AD119AA@redhat.com>
References: <FB9AA4B7-D905-49DE-8F9B-1A3ACC314C34@redhat.com>
	<CAJgngAdP-LPgTE+gmqXYxphJMJcRF65KkGo9dbFM1mOoJm3Gdg@mail.gmail.com>
	<5CA8AF32-E005-4156-BFD3-A9D18AD119AA@redhat.com>
Message-ID: <CAJgngAewCutXTg0yfFfNpXUZcxJ5PifPNYo3N2SmK-ZCOKsxxA@mail.gmail.com>

I agree with you on usability. If possible just re-direct back is is the
best, but not sure if that's possible especially considering custom
authenticators. If I click back button and displayed a "form no longer
valid" page I'd at least assume that I'm not allowed to resubmit the form,
so I thought that could be a compromise.

I don't actually get that behavior and Google shows me the password page
again when I click the back button. Maybe it's because I've got totp
enabled, but it's strange that it displays password page, not totp page
(which was the last page on login flow).

On 8 April 2016 at 09:59, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:

> Thanks Stian for getting my point.
>
> Here is screencast how google works for me:
> https://dl.dropboxusercontent.com/u/40512422/devel/keycloak/google-login-back-button.mov
>
> Let me describe these things from really ?end user? perspective.
>
> If I?m trying to feel like a really ?end-user? the only thing that Login
> Server is responsible for is provide me a way (registration or login) to
> give me access to let?s call it ?secured content".
> I don?t care about login server. I care about the secured content.
> If I?m successfully logged in and SSO session exists I should not see any
> ?no longer valid? message because it?s not true. I?m logged in so
> everything is OK and I didn?t make any mistake. I successfully logs in and
> should get the ?secured content?.
>
>
> In case the login server would give me ?page is no longer valid? brings to
> my mind something like ?I was logged out? or ?I did something wrong? or ?I
> need to do something again like do login again".
>
>
> Thanks,
>
> Libor Krzy?anek
> Principal Software Engineer
> Red Hat Developers | Engineering
>
> On Apr 7, 2016, at 3:31 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> I agree it should either show a page is no longer valid message or
> redirect back to origin as you're suggesting. The latter is the best, but
> we need to be able to identify that's actually what should be done. I tried
> with Google and it actually didn't work for me, it showed me the password
> page again.
>
> On 7 April 2016 at 13:47, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:
>
>> Hi,
>> when user successfully logs in (either after registration or login) then
>> hitting back button shows KC page (login/registration) again.
>>
>> This looks to be a bug to me because user is logged in and should be
>> allowed to do only logout. No login or registration.
>>
>> I tried how google.com behaves and when you successfully logs in then
>> hitting back button is handled correctly - their sso realize that you?re
>> logged in and then user is redirected to requested page. No login page.
>>
>> I think KC should follow same behavior.
>>
>> Jira for login flow: https://issues.jboss.org/browse/KEYCLOAK-2768
>> Jira for reg. flow: https://issues.jboss.org/browse/KEYCLOAK-2740
>>
>> Thanks,
>>
>> Libor Krzy?anek
>> Principal Software Engineer
>> Red Hat Developers | Engineering
>>
>>
>> _______________________________________________
>> 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/20160411/e1d7dbda/attachment-0001.html 

From mposolda at redhat.com  Mon Apr 11 08:48:08 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 11 Apr 2016 14:48:08 +0200
Subject: [keycloak-dev] Attribute-based Access Control
In-Reply-To: <CALvqGZDStXX=UH5Q4Lkhwp8E9d+=QRtLjQEpw2G+SrpFWegPgA@mail.gmail.com>
References: <CALvqGZDStXX=UH5Q4Lkhwp8E9d+=QRtLjQEpw2G+SrpFWegPgA@mail.gmail.com>
Message-ID: <570B9D08.7080202@redhat.com>

There is authorization prototype by Pedro in progress. You can check it 
here https://github.com/pedroigor/keycloak-authz

Marek

On 09/04/16 14:45, Duarte wrote:
> Hi,
>
> My name is Duarte, and this is the first post on this dev-list.
>
> My question is regarding Attribute-based Access Control. Is there any 
> usable feature for Attribute based decision for resource access? Or do 
> I have to make my own?
>
> Basically what I want to do is a PEP (Policy Enforcement Point) and a 
> PDP (Policy Decision Point) on Keycloak with external attributes 
> (Federated).
>
> e.g: User has attribute of X can only access files A<->B and User with 
> attribute Y can only access B<->L.
>
> Thank you.
>
> -- 
>
>
>
> _______________________________________________
> 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/20160411/5949802c/attachment.html 

From psilva at redhat.com  Mon Apr 11 09:42:07 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 11 Apr 2016 09:42:07 -0400 (EDT)
Subject: [keycloak-dev] Attribute-based Access Control
In-Reply-To: <570B9D08.7080202@redhat.com>
References: <CALvqGZDStXX=UH5Q4Lkhwp8E9d+=QRtLjQEpw2G+SrpFWegPgA@mail.gmail.com>
	<570B9D08.7080202@redhat.com>
Message-ID: <843038887.49607902.1460382127605.JavaMail.zimbra@redhat.com>

Like Marek said, we are working a new set of functionalities to leverage Keycloak's authorization model to also support fine-grained permissions.

By fine-grained, that means you'll be able to manage your resources and their respective scopes and associate them with authorization policies that rule who,when,how access should be granted. Where these policies can be based on ABAC, RBAC, Context-based, etc. Some policies can be even written using Javascript (which gives you great flexibility) or JBoss Drools.

Right now, I'm merging that code that Marek pointed out with upstream/master. However, For latest code about this stuff, please consider [1].

I hope to get a PR this week, but fell free to take a look and try it out :)

[1] https://github.com/pedroigor/keycloak/tree/KEYCLOAK-2753

----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: "Duarte" <duarteetraud at gmail.com>, keycloak-dev at lists.jboss.org
Cc: "Pedro Igor Silva" <psilva at redhat.com>
Sent: Monday, April 11, 2016 9:48:08 AM
Subject: Re: [keycloak-dev] Attribute-based Access Control

There is authorization prototype by Pedro in progress. You can check it 
here https://github.com/pedroigor/keycloak-authz

Marek

On 09/04/16 14:45, Duarte wrote:
> Hi,
>
> My name is Duarte, and this is the first post on this dev-list.
>
> My question is regarding Attribute-based Access Control. Is there any 
> usable feature for Attribute based decision for resource access? Or do 
> I have to make my own?
>
> Basically what I want to do is a PEP (Policy Enforcement Point) and a 
> PDP (Policy Decision Point) on Keycloak with external attributes 
> (Federated).
>
> e.g: User has attribute of X can only access files A<->B and User with 
> attribute Y can only access B<->L.
>
> Thank you.
>
> -- 
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From duarteetraud at gmail.com  Mon Apr 11 10:28:26 2016
From: duarteetraud at gmail.com (Duarte)
Date: Mon, 11 Apr 2016 15:28:26 +0100
Subject: [keycloak-dev] Attribute-based Access Control
In-Reply-To: <843038887.49607902.1460382127605.JavaMail.zimbra@redhat.com>
References: <CALvqGZDStXX=UH5Q4Lkhwp8E9d+=QRtLjQEpw2G+SrpFWegPgA@mail.gmail.com>
	<570B9D08.7080202@redhat.com>
	<843038887.49607902.1460382127605.JavaMail.zimbra@redhat.com>
Message-ID: <CALvqGZAk2rHp5hus5Qc_SzPXZzgtp3VGd4N2E1CVwYcfVW1POg@mail.gmail.com>

Hi Marek, Pedro

Thank you for the replies.

Very interesting indeed I'm surely take a look into this!! Let me know If I
can help you with anything.

Just one question before I pull this version, do you have the web interface
to manage the policies?


Cheers.

2016-04-11 14:42 GMT+01:00 Pedro Igor Silva <psilva at redhat.com>:

> Like Marek said, we are working a new set of functionalities to leverage
> Keycloak's authorization model to also support fine-grained permissions.
>
> By fine-grained, that means you'll be able to manage your resources and
> their respective scopes and associate them with authorization policies that
> rule who,when,how access should be granted. Where these policies can be
> based on ABAC, RBAC, Context-based, etc. Some policies can be even written
> using Javascript (which gives you great flexibility) or JBoss Drools.
>
> Right now, I'm merging that code that Marek pointed out with
> upstream/master. However, For latest code about this stuff, please consider
> [1].
>
> I hope to get a PR this week, but fell free to take a look and try it out
> :)
>
> [1] https://github.com/pedroigor/keycloak/tree/KEYCLOAK-2753
>
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Duarte" <duarteetraud at gmail.com>, keycloak-dev at lists.jboss.org
> Cc: "Pedro Igor Silva" <psilva at redhat.com>
> Sent: Monday, April 11, 2016 9:48:08 AM
> Subject: Re: [keycloak-dev] Attribute-based Access Control
>
> There is authorization prototype by Pedro in progress. You can check it
> here https://github.com/pedroigor/keycloak-authz
>
> Marek
>
> On 09/04/16 14:45, Duarte wrote:
> > Hi,
> >
> > My name is Duarte, and this is the first post on this dev-list.
> >
> > My question is regarding Attribute-based Access Control. Is there any
> > usable feature for Attribute based decision for resource access? Or do
> > I have to make my own?
> >
> > Basically what I want to do is a PEP (Policy Enforcement Point) and a
> > PDP (Policy Decision Point) on Keycloak with external attributes
> > (Federated).
> >
> > e.g: User has attribute of X can only access files A<->B and User with
> > attribute Y can only access B<->L.
> >
> > Thank you.
> >
> > --
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
[Never forget "Security is not a product, but a process"]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160411/9e68b2ac/attachment.html 

From psilva at redhat.com  Mon Apr 11 10:38:24 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 11 Apr 2016 10:38:24 -0400 (EDT)
Subject: [keycloak-dev] Attribute-based Access Control
In-Reply-To: <CALvqGZAk2rHp5hus5Qc_SzPXZzgtp3VGd4N2E1CVwYcfVW1POg@mail.gmail.com>
References: <CALvqGZDStXX=UH5Q4Lkhwp8E9d+=QRtLjQEpw2G+SrpFWegPgA@mail.gmail.com>
	<570B9D08.7080202@redhat.com>
	<843038887.49607902.1460382127605.JavaMail.zimbra@redhat.com>
	<CALvqGZAk2rHp5hus5Qc_SzPXZzgtp3VGd4N2E1CVwYcfVW1POg@mail.gmail.com>
Message-ID: <224896716.49648688.1460385504234.JavaMail.zimbra@redhat.com>

Yeah. There are a set of UIs from where you can manage things such as:

 * Manage Resource Servers (the client applications acting as a RS)
 * Manage Resources
 * Manage Scopes
 * Manage Permissions (resource and scope based permissions)
 * Manage Policies (which are used to associated with permissions above)

Beside that, there are some built-in "enforcers"/PEPs that you can use to protect:

  * JAX-RS resources
  * Servlet resources

That is what we are considering in the first release. But there are a plenty of other things we are planning to add in the future ...

Please, feel free to contact me on IRC #keycloak for more info or any issue.

Regards.
Pedro Igor

----- Original Message -----
From: "Duarte" <duarteetraud at gmail.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
Sent: Monday, April 11, 2016 11:28:26 AM
Subject: Re: [keycloak-dev] Attribute-based Access Control

Hi Marek, Pedro

Thank you for the replies.

Very interesting indeed I'm surely take a look into this!! Let me know If I
can help you with anything.

Just one question before I pull this version, do you have the web interface
to manage the policies?


Cheers.

2016-04-11 14:42 GMT+01:00 Pedro Igor Silva <psilva at redhat.com>:

> Like Marek said, we are working a new set of functionalities to leverage
> Keycloak's authorization model to also support fine-grained permissions.
>
> By fine-grained, that means you'll be able to manage your resources and
> their respective scopes and associate them with authorization policies that
> rule who,when,how access should be granted. Where these policies can be
> based on ABAC, RBAC, Context-based, etc. Some policies can be even written
> using Javascript (which gives you great flexibility) or JBoss Drools.
>
> Right now, I'm merging that code that Marek pointed out with
> upstream/master. However, For latest code about this stuff, please consider
> [1].
>
> I hope to get a PR this week, but fell free to take a look and try it out
> :)
>
> [1] https://github.com/pedroigor/keycloak/tree/KEYCLOAK-2753
>
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Duarte" <duarteetraud at gmail.com>, keycloak-dev at lists.jboss.org
> Cc: "Pedro Igor Silva" <psilva at redhat.com>
> Sent: Monday, April 11, 2016 9:48:08 AM
> Subject: Re: [keycloak-dev] Attribute-based Access Control
>
> There is authorization prototype by Pedro in progress. You can check it
> here https://github.com/pedroigor/keycloak-authz
>
> Marek
>
> On 09/04/16 14:45, Duarte wrote:
> > Hi,
> >
> > My name is Duarte, and this is the first post on this dev-list.
> >
> > My question is regarding Attribute-based Access Control. Is there any
> > usable feature for Attribute based decision for resource access? Or do
> > I have to make my own?
> >
> > Basically what I want to do is a PEP (Policy Enforcement Point) and a
> > PDP (Policy Decision Point) on Keycloak with external attributes
> > (Federated).
> >
> > e.g: User has attribute of X can only access files A<->B and User with
> > attribute Y can only access B<->L.
> >
> > Thank you.
> >
> > --
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
[Never forget "Security is not a product, but a process"]

From bruno at abstractj.org  Mon Apr 11 11:09:15 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 11 Apr 2016 15:09:15 +0000
Subject: [keycloak-dev] Node.js adapter releases
Message-ID: <CAM5SUC45=ztbb27xLvrmDNCqtFTp7G+pc3ggRuRDAXvfszO62Q@mail.gmail.com>

Good morning,

Today I was chatting with Lance about the release cadence for Node.js
adapters.

My initial idea was to release the adapters at exactly the same release
dates as the official Keycloak release in order to guarantee compatibility.
For critical/urgent patches, we just release those modules based on our
judgment.

Lance would like more flexibility between those releases. For example,
release npm modules before the official release for situations where a user
wants some new capability that is perhaps unrelated to changes in KC itself
e.g. a move to promises.

I don't have any problems on keeping Node.js adapters' release independent
from official KC release, but would like to hear more opinions about it.

-- 


-
abstractj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160411/e25b7058/attachment.html 

From sthorger at redhat.com  Mon Apr 11 12:43:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 11 Apr 2016 18:43:16 +0200
Subject: [keycloak-dev] Node.js adapter releases
In-Reply-To: <CAJgngAedFWi9-DSSHkm-7F+3s0aFpniDtgnwpAVPDKbLhY9t2g@mail.gmail.com>
References: <CAM5SUC45=ztbb27xLvrmDNCqtFTp7G+pc3ggRuRDAXvfszO62Q@mail.gmail.com>
	<CAJgngAfUXVV37HnvcVmO7=kncm09=wD0x8nhs27s_T=4LMLTsA@mail.gmail.com>
	<CAJgngAcbV4AUobGuX6j=Gxo9F8zNzBNfQ4+4yGa-WqaZ6=BEkg@mail.gmail.com>
	<CAJgngAcOiZwisSpum2cGT1x-pJGmdxxo-oGhpVL8G=-fU5Wy0A@mail.gmail.com>
	<CAJgngAedFWi9-DSSHkm-7F+3s0aFpniDtgnwpAVPDKbLhY9t2g@mail.gmail.com>
Message-ID: <CAJgngAfbmax_c0F91YdV=srBx+2PxoQNQmd9MqCCE5WUScSKjA@mail.gmail.com>

We discussed this at the f2f and I believe we should keep it consistent
across all adapters.

The decision was to have all adapters released when the server is released
and they will have the same version numbers. We will also make sure release
notes mark which adapters have changed and also which are required to
update (either due to compatibility changes or security related fixes).

So I'd like the ability to release nodejs adapters at the same time I do
the release of the server.

We can certainly discuss changes to the above, but it should be consistent
for all our adapters.
On 11 Apr 2016 17:09, "Bruno Oliveira" <bruno at abstractj.org> wrote:

Good morning,

Today I was chatting with Lance about the release cadence for Node.js
adapters.

My initial idea was to release the adapters at exactly the same release
dates as the official Keycloak release in order to guarantee compatibility.
For critical/urgent patches, we just release those modules based on our
judgment.

Lance would like more flexibility between those releases. For example,
release npm modules before the official release for situations where a user
wants some new capability that is perhaps unrelated to changes in KC itself
e.g. a move to promises.

I don't have any problems on keeping Node.js adapters' release independent
from official KC release, but would like to hear more opinions about it.

-- 


-
abstractj

_______________________________________________
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/20160411/8e5b86bb/attachment-0001.html 

From bruno at abstractj.org  Mon Apr 11 14:21:05 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 11 Apr 2016 18:21:05 +0000
Subject: [keycloak-dev] Node.js adapter releases
In-Reply-To: <CAJgngAfbmax_c0F91YdV=srBx+2PxoQNQmd9MqCCE5WUScSKjA@mail.gmail.com>
References: <CAM5SUC45=ztbb27xLvrmDNCqtFTp7G+pc3ggRuRDAXvfszO62Q@mail.gmail.com>
	<CAJgngAfUXVV37HnvcVmO7=kncm09=wD0x8nhs27s_T=4LMLTsA@mail.gmail.com>
	<CAJgngAcbV4AUobGuX6j=Gxo9F8zNzBNfQ4+4yGa-WqaZ6=BEkg@mail.gmail.com>
	<CAJgngAcOiZwisSpum2cGT1x-pJGmdxxo-oGhpVL8G=-fU5Wy0A@mail.gmail.com>
	<CAJgngAedFWi9-DSSHkm-7F+3s0aFpniDtgnwpAVPDKbLhY9t2g@mail.gmail.com>
	<CAJgngAfbmax_c0F91YdV=srBx+2PxoQNQmd9MqCCE5WUScSKjA@mail.gmail.com>
Message-ID: <CAM5SUC7qTA9Kx2WhQntg+3x6sSQw4vn-sM30X8+S8L7bMa2n4w@mail.gmail.com>

+1 for consistency and release dates. But I'd keep the release version
independent, move from 0.0.16 to 1.9.2 for example, is a huge bump.

On Mon, Apr 11, 2016 at 1:43 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> We discussed this at the f2f and I believe we should keep it consistent
> across all adapters.
>
> The decision was to have all adapters released when the server is released
> and they will have the same version numbers. We will also make sure release
> notes mark which adapters have changed and also which are required to
> update (either due to compatibility changes or security related fixes).
>
> So I'd like the ability to release nodejs adapters at the same time I do
> the release of the server.
>
> We can certainly discuss changes to the above, but it should be consistent
> for all our adapters.
> On 11 Apr 2016 17:09, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>
> Good morning,
>
> Today I was chatting with Lance about the release cadence for Node.js
> adapters.
>
> My initial idea was to release the adapters at exactly the same release
> dates as the official Keycloak release in order to guarantee compatibility.
> For critical/urgent patches, we just release those modules based on our
> judgment.
>
> Lance would like more flexibility between those releases. For example,
> release npm modules before the official release for situations where a user
> wants some new capability that is perhaps unrelated to changes in KC
> itself e.g. a move to promises.
>
> I don't have any problems on keeping Node.js adapters' release independent
> from official KC release, but would like to hear more opinions about it.
>
> --
>
>
> -
> abstractj
>
> _______________________________________________
> 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/20160411/5e05b198/attachment.html 

From lball at redhat.com  Mon Apr 11 14:27:42 2016
From: lball at redhat.com (Lance Ball)
Date: Mon, 11 Apr 2016 14:27:42 -0400
Subject: [keycloak-dev] Node.js adapter releases
In-Reply-To: <CAM5SUC7qTA9Kx2WhQntg+3x6sSQw4vn-sM30X8+S8L7bMa2n4w@mail.gmail.com>
References: <CAM5SUC45=ztbb27xLvrmDNCqtFTp7G+pc3ggRuRDAXvfszO62Q@mail.gmail.com>
	<CAJgngAfUXVV37HnvcVmO7=kncm09=wD0x8nhs27s_T=4LMLTsA@mail.gmail.com>
	<CAJgngAcbV4AUobGuX6j=Gxo9F8zNzBNfQ4+4yGa-WqaZ6=BEkg@mail.gmail.com>
	<CAJgngAcOiZwisSpum2cGT1x-pJGmdxxo-oGhpVL8G=-fU5Wy0A@mail.gmail.com>
	<CAJgngAedFWi9-DSSHkm-7F+3s0aFpniDtgnwpAVPDKbLhY9t2g@mail.gmail.com>
	<CAJgngAfbmax_c0F91YdV=srBx+2PxoQNQmd9MqCCE5WUScSKjA@mail.gmail.com>
	<CAM5SUC7qTA9Kx2WhQntg+3x6sSQw4vn-sM30X8+S8L7bMa2n4w@mail.gmail.com>
Message-ID: <CABRDmifsfQnkSu-mdwzurt+hZG-dNa4PO3jrUxsKgaC3_yQVvw@mail.gmail.com>

I agree that keeping version numbers consistent might be questionable.
There is the big bump as Bruno notes, but also the npm modules need to be
able to publish in the absence of a keycloak release in the event that
there are bugs which need to be addressed in an adapter but not in keycloak
itself - e.g. https://issues.jboss.org/browse/KEYCLOAK-2798.

Lance

On Mon, Apr 11, 2016 at 2:21 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> +1 for consistency and release dates. But I'd keep the release version
> independent, move from 0.0.16 to 1.9.2 for example, is a huge bump.
>
> On Mon, Apr 11, 2016 at 1:43 PM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> We discussed this at the f2f and I believe we should keep it consistent
>> across all adapters.
>>
>> The decision was to have all adapters released when the server is
>> released and they will have the same version numbers. We will also make
>> sure release notes mark which adapters have changed and also which are
>> required to update (either due to compatibility changes or security related
>> fixes).
>>
>> So I'd like the ability to release nodejs adapters at the same time I do
>> the release of the server.
>>
>> We can certainly discuss changes to the above, but it should be
>> consistent for all our adapters.
>> On 11 Apr 2016 17:09, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>>
>> Good morning,
>>
>> Today I was chatting with Lance about the release cadence for Node.js
>> adapters.
>>
>> My initial idea was to release the adapters at exactly the same release
>> dates as the official Keycloak release in order to guarantee compatibility.
>> For critical/urgent patches, we just release those modules based on our
>> judgment.
>>
>> Lance would like more flexibility between those releases. For example,
>> release npm modules before the official release for situations where a user
>> wants some new capability that is perhaps unrelated to changes in KC
>> itself e.g. a move to promises.
>>
>> I don't have any problems on keeping Node.js adapters' release
>> independent from official KC release, but would like to hear more opinions
>> about it.
>>
>> --
>>
>>
>> -
>> abstractj
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160411/d60d43de/attachment.html 

From sthorger at redhat.com  Tue Apr 12 00:29:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Apr 2016 06:29:12 +0200
Subject: [keycloak-dev] Node.js adapter releases
In-Reply-To: <CABRDmifsfQnkSu-mdwzurt+hZG-dNa4PO3jrUxsKgaC3_yQVvw@mail.gmail.com>
References: <CAM5SUC45=ztbb27xLvrmDNCqtFTp7G+pc3ggRuRDAXvfszO62Q@mail.gmail.com>
	<CAJgngAfUXVV37HnvcVmO7=kncm09=wD0x8nhs27s_T=4LMLTsA@mail.gmail.com>
	<CAJgngAcbV4AUobGuX6j=Gxo9F8zNzBNfQ4+4yGa-WqaZ6=BEkg@mail.gmail.com>
	<CAJgngAcOiZwisSpum2cGT1x-pJGmdxxo-oGhpVL8G=-fU5Wy0A@mail.gmail.com>
	<CAJgngAedFWi9-DSSHkm-7F+3s0aFpniDtgnwpAVPDKbLhY9t2g@mail.gmail.com>
	<CAJgngAfbmax_c0F91YdV=srBx+2PxoQNQmd9MqCCE5WUScSKjA@mail.gmail.com>
	<CAM5SUC7qTA9Kx2WhQntg+3x6sSQw4vn-sM30X8+S8L7bMa2n4w@mail.gmail.com>
	<CABRDmifsfQnkSu-mdwzurt+hZG-dNa4PO3jrUxsKgaC3_yQVvw@mail.gmail.com>
Message-ID: <CAJgngAcJHSbiDa02XX+AkiS+6HHnSqe-nQ_-uiLPq4SmLH+4qQ@mail.gmail.com>

Having the same version makes it much easier for people to grab a version
they know works with a specific Keycloak version. It also makes it simpler
when we release.

Keycloak has a 6 week release cadence and adapters shouldn't be released
more frequently. Rather they should be released at the same time as the
server and by the same release job in Jenkins.

To become a first class citizen an adapter has to:

* Release at same time as Keycloak server (every ~6 weeks). We test and
release everything as a bundle and don't have the resources to maintain
separate release cycles. I also want all adapters to be consistent here.
* Documentation - we're going to have a adapters documentation, it will
have a separate chapter for each adapter. Each adapter chapter will have a
getting started and a reference/developer guide. There's also need for the
relevant api docs in whatever format is most popular for a specific language
* Examples - not sure where these will live. Maybe all examples for all
adapters are in one repo

Any changes to the above has to be raised. If you really want to discuss
that then send a generic message to keycloak-dev list, basically don't
include NodeJS in the title ;).

On 11 April 2016 at 20:27, Lance Ball <lball at redhat.com> wrote:

> I agree that keeping version numbers consistent might be questionable.
> There is the big bump as Bruno notes, but also the npm modules need to be
> able to publish in the absence of a keycloak release in the event that
> there are bugs which need to be addressed in an adapter but not in keycloak
> itself - e.g. https://issues.jboss.org/browse/KEYCLOAK-2798.
>
> Lance
>
> On Mon, Apr 11, 2016 at 2:21 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> +1 for consistency and release dates. But I'd keep the release version
>> independent, move from 0.0.16 to 1.9.2 for example, is a huge bump.
>>
>> On Mon, Apr 11, 2016 at 1:43 PM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> We discussed this at the f2f and I believe we should keep it consistent
>>> across all adapters.
>>>
>>> The decision was to have all adapters released when the server is
>>> released and they will have the same version numbers. We will also make
>>> sure release notes mark which adapters have changed and also which are
>>> required to update (either due to compatibility changes or security related
>>> fixes).
>>>
>>> So I'd like the ability to release nodejs adapters at the same time I do
>>> the release of the server.
>>>
>>> We can certainly discuss changes to the above, but it should be
>>> consistent for all our adapters.
>>> On 11 Apr 2016 17:09, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>>>
>>> Good morning,
>>>
>>> Today I was chatting with Lance about the release cadence for Node.js
>>> adapters.
>>>
>>> My initial idea was to release the adapters at exactly the same release
>>> dates as the official Keycloak release in order to guarantee compatibility.
>>> For critical/urgent patches, we just release those modules based on our
>>> judgment.
>>>
>>> Lance would like more flexibility between those releases. For example,
>>> release npm modules before the official release for situations where a user
>>> wants some new capability that is perhaps unrelated to changes in KC
>>> itself e.g. a move to promises.
>>>
>>> I don't have any problems on keeping Node.js adapters' release
>>> independent from official KC release, but would like to hear more opinions
>>> about it.
>>>
>>> --
>>>
>>>
>>> -
>>> abstractj
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/a66931ba/attachment-0001.html 

From sthorger at redhat.com  Tue Apr 12 00:48:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Apr 2016 06:48:39 +0200
Subject: [keycloak-dev] [keycloak-user] Logouts / how to disable
	keycloak "user session" cache?
In-Reply-To: <8E6D7F6B-C214-454F-BA0C-F8ECF4ECC894@smartling.com>
References: <EA3467C5-7A77-4526-888F-6AEF92CFDF6C@datek.no>
	<CAJgngAdF95op7hb-tYrXOLj6t=Luf2M2Z3CXzF_v+0FD49D-kw@mail.gmail.com>
	<CAK-7U1iqT77oK_AF_eNHf+gm49c=Ezv2qSP9SyevxRRdVSZS7g@mail.gmail.com>
	<8E6D7F6B-C214-454F-BA0C-F8ECF4ECC894@smartling.com>
Message-ID: <CAJgngAeiaRao+3Y0p2pP1rBre-CA6L1Vg2TPEzE5+zVjNdJ1sQ@mail.gmail.com>

+1 To running Keycloak on AWS section to docs. Do you want to contribute
that? Not sure about Docker images, we already have more than I'd like to
maintain.

On 7 April 2016 at 22:56, Scott Rossillo <srossillo at smartling.com> wrote:

> Hi!
>
> We completed the final steps to getting this working on Amazon AWS with
> Docker using Keycloak 1.9.x. Since we already have a database, we used
> JDBC_PING not to add S3 as yet another dependency.
>
> The changes are here[0] for now. Would Keycloak devs be interested in
> adding a running Keycloak on AWS section or another sample docker image?
>
> There are 3 steps / files:
>
> 1. configureCache.xsl sets up Infinispan correctly
> 2. start.sh - Uses Amazon APIs via HTTP to get the correct instance IP
> information
> 3. 30_docker_ports.config - if using Docker, this shell script runs on
> deploy to expose the cluster port to the EC2 interface. Needed with
> Beanstalk, maybe not with ECS
>
> [0]: https://gist.github.com/foo4u/ad2fa7251ac5b4d4fd318f668f50f7ac
>
> Best,
> Scott
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> On Apr 7, 2016, at 6:44 AM, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
> Hello,
>
> have a look at this thread:
> http://lists.jboss.org/pipermail/keycloak-user/2016-February/004935.html
>
> Cheers,
> Thomas
>
> 2016-04-07 12:40 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> It is not currently possible to run multiple nodes without clustering.
>> However, it's possible to configure JGroups to work on AWS. I can't
>> remember the configuration required though, but if you search the user
>> mailing list you'll find instructions or google for JGroups and AWS.
>>
>> On 7 April 2016 at 10:22, Christian Schwarz <christian at datek.no> wrote:
>>
>>> Hi!
>>>
>>> I'm trying to setup a keycloak cluster on AWS, which does not support
>>> UDP multicast. IP addresses of the nodes are also not known in advance (I'm
>>> using docker-cloud), so Infinispan/JGroups ("keycloak-ha-posgres" docker
>>> image) for user session replication will not work (seems that it requires
>>> either UDP multicast or IP addresses known in advance).
>>>
>>> The main problem I have is that logout is not working propertly. I only
>>> get logged out from one of the two keycloak nodes.
>>>
>>> I have tried to disable the user cache (by setting
>>> userCache.default.enabled = false) and to disable infinispan (by using
>>> ?keycloak-postgres? docker image), but to no avail. The ?other? keycloak
>>> node still thinks that the user is logged in, it?s not refreshing the user
>>> session from the database even if user cache and infinispan cluster cache
>>> is disbled.
>>>
>>> => Is there a possibility of using the database as a synchronization
>>> point between keycloak nodes? (i.e. each node always checks logout status
>>> in the database)
>>> Or is there another way of getting a keycloak cluster up and running on
>>> AWS when IP addresses are not known in advance?
>>>
>>> I hope there is a way? :)
>>>
>>> Kind regards,
>>> Christian
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/ffaece5f/attachment.html 

From jayapriya.atheesan at gmail.com  Tue Apr 12 03:01:45 2016
From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN)
Date: Tue, 12 Apr 2016 12:31:45 +0530
Subject: [keycloak-dev] Social media Login using keycloak
Message-ID: <570c9d60.4a7a420a.d2fe4.ffffe020@mx.google.com>

Hi Team,

 

We have angular js integrated with keycloak services. When the person logins
to our application, we enable social media login also.

But after login, we would like to know which social media the user used for
login.

 

Is it possible by anyways? Waiting on ur reply.. It is little urgent for us.

 

Thanks,

Jayapriya Atheesan

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/41a48816/attachment.html 

From Erwin.Oldenkamp at topicus.nl  Tue Apr 12 03:26:36 2016
From: Erwin.Oldenkamp at topicus.nl (Erwin Oldenkamp)
Date: Tue, 12 Apr 2016 07:26:36 +0000
Subject: [keycloak-dev] Filter user federation provider on Realms
Message-ID: <772BBF6A29B12A4CA40F66BA2C13DFDB029F3D15@EXCH-MBX01.topicus.local>

Hallo,

My name is Erwin, and I've got a question regarding the Kerberos authorization.

We want to use keycloak for a project where we need to let people login through Kerberos.
The user federation providers are only sortable by priority but we'll probably get 20 or more providers for this application.
Now we want filter based on the real the user is in. I've tried a few things and I saw it was possible to decrypt the Kerberos token with base64.
After that it was possible to add something of the following on line 430 of file
String decodedToken = new String(Base64.decode(spnegoToken));
if(!decodedToken.contains(kerberosConfig.getKerberosRealm()))
{
   return CredentialValidationOutput.failed();
}
This way the token won't be validated against the Kerberos server that isn't configured for the specific realm.
I'm not too familiour with the whole Kerberos token, so I don't know if this will work in all situations.
Can someone tell me if this is the "correct" way of doing this, or is there some other way I haven't seen yet?

Thank in advance,



Erwin Oldenkamp

[http://www.topicusfinance.com/mailsignature/images/phone.png] +31(0)88 77 88 990
[http://www.topicusfinance.com/mailsignature/images/email.png] erwin.oldenkamp at topicus.nl<mailto:erwin.oldenkamp at topicus.nl>

[http://www.topicusfinance.com/mailsignature/images/logo.png]<http://www.topicusfinance.com/>
Koggelaan 3-A
8017 JH Zwolle
[Website]<http://www.topicusfinance.com/> [Linkedin] <https://www.linkedin.com/company/topicus-finance>  [Twitter] <https://twitter.com/TopicusFinance>  [Facebook] <https://www.facebook.com/Topicusbv?fref=ts>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 698 bytes
Desc: image001.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0008.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 686 bytes
Desc: image002.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0009.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 2117 bytes
Desc: image003.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0010.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 838 bytes
Desc: image004.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0011.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image005.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0012.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image006.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0013.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 819 bytes
Desc: image007.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0014.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.jpg
Type: image/jpeg
Size: 828 bytes
Desc: image008.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/20f8a2b2/attachment-0015.jpg 

From guus.der.kinderen at gmail.com  Tue Apr 12 06:10:01 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Tue, 12 Apr 2016 12:10:01 +0200
Subject: [keycloak-dev] Bug in UI?
Message-ID: <CAMJaV9mo13KS+HVFyJzcmxcC0noPs-yDwkvxDJZaSjUT7o+6XA@mail.gmail.com>

Hi,

I did not try to reproduce this on master branch, but got it twice now on
1.9.x. The branch HEAD is commit b01f522acea6b6c5c6f487dc626a24ca928da77d

After I build the distribution...

$ mvn clean install -DskipTests -Pdistribution


... extract the distribution ...

$ cd /distribution/server-dist/target/
$ tar zxvf keycloak-1.9.2.Final-SNAPSHOT.tar.gz


... and start a standalone instance ...

$ cd /keycloak-1.9.2.Final-SNAPSHOT/bin
$ ./standalone.sh

... open the webpage at http://localhost:8080/auth
... create a new user
... login to the administration console with that user
... go to the list of clients
... and open (or click 'edit') on any of the clients

Then the webpage that I'm looking at appears to be broken. I'm looking at
the template itself, I think.

Is this me, or can someone reproduce this?

 - Guus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/00ee9748/attachment.html 

From cpitman at redhat.com  Tue Apr 12 09:19:25 2016
From: cpitman at redhat.com (Chris Pitman)
Date: Tue, 12 Apr 2016 09:19:25 -0400 (EDT)
Subject: [keycloak-dev] Social media Login using keycloak
In-Reply-To: <570c9d60.4a7a420a.d2fe4.ffffe020@mx.google.com>
References: <570c9d60.4a7a420a.d2fe4.ffffe020@mx.google.com>
Message-ID: <2003225553.50039507.1460467165919.JavaMail.zimbra@redhat.com>

I haven't tried this, but I think this is what you are looking for: http://keycloak.github.io/docs/userguide/keycloak-server/html/identity-broker.html#d4e2242

By the way, questions like this belong more on the keycloak-user mailing list.

Chris Pitman
Architect, Red Hat Consulting

----- Original Message -----
> 
> 
> Hi Team,
> 
> 
> 
> We have angular js integrated with keycloak services. When the person logins
> to our application, we enable social media login also.
> 
> But after login, we would like to know which social media the user used for
> login.
> 
> 
> 
> Is it possible by anyways? Waiting on ur reply.. It is little urgent for us.
> 
> 
> 
> Thanks,
> 
> Jayapriya Atheesan
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From lholmqui at redhat.com  Tue Apr 12 09:24:20 2016
From: lholmqui at redhat.com (Luke Holmquist)
Date: Tue, 12 Apr 2016 09:24:20 -0400
Subject: [keycloak-dev] Node.js adapter releases
In-Reply-To: <CAJgngAcJHSbiDa02XX+AkiS+6HHnSqe-nQ_-uiLPq4SmLH+4qQ@mail.gmail.com>
References: <CAM5SUC45=ztbb27xLvrmDNCqtFTp7G+pc3ggRuRDAXvfszO62Q@mail.gmail.com>
	<CAJgngAfUXVV37HnvcVmO7=kncm09=wD0x8nhs27s_T=4LMLTsA@mail.gmail.com>
	<CAJgngAcbV4AUobGuX6j=Gxo9F8zNzBNfQ4+4yGa-WqaZ6=BEkg@mail.gmail.com>
	<CAJgngAcOiZwisSpum2cGT1x-pJGmdxxo-oGhpVL8G=-fU5Wy0A@mail.gmail.com>
	<CAJgngAedFWi9-DSSHkm-7F+3s0aFpniDtgnwpAVPDKbLhY9t2g@mail.gmail.com>
	<CAJgngAfbmax_c0F91YdV=srBx+2PxoQNQmd9MqCCE5WUScSKjA@mail.gmail.com>
	<CAM5SUC7qTA9Kx2WhQntg+3x6sSQw4vn-sM30X8+S8L7bMa2n4w@mail.gmail.com>
	<CABRDmifsfQnkSu-mdwzurt+hZG-dNa4PO3jrUxsKgaC3_yQVvw@mail.gmail.com>
	<CAJgngAcJHSbiDa02XX+AkiS+6HHnSqe-nQ_-uiLPq4SmLH+4qQ@mail.gmail.com>
Message-ID: <CALD3Fd0Bp1LC+wz1bOh5H2ix7=2FZeM-96Tba47r3=GJeofSJw@mail.gmail.com>

On Tue, Apr 12, 2016 at 12:29 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Having the same version makes it much easier for people to grab a version
> they know works with a specific Keycloak version. It also makes it simpler
> when we release.
>
> Keycloak has a 6 week release cadence
>
While this probably works most of the time,  i'm wondering what happens,
for example, if in the node.js adapter there is a security vulnerability in
one of the dependent packages that is discovered a couple days after a
release,  would you then need to create a new release of all of Keycloak?
 that is fine, i'm just wondering if thats what would happen since that
could be a real possibility.  so for an issue like this:
https://issues.jboss.org/browse/KEYCLOAK-2798. a full keycloak release
would need to happen then?

*everything i said above only applies if that node adapter is a full class
citizen,  obviously "community" things are different *



> and adapters shouldn't be released more frequently. Rather they should be
> released at the same time as the server and by the same release job in
> Jenkins.
>
> To become a first class citizen an adapter has to:
>
> * Release at same time as Keycloak server (every ~6 weeks). We test and
> release everything as a bundle and don't have the resources to maintain
> separate release cycles. I also want all adapters to be consistent here.
> * Documentation - we're going to have a adapters documentation, it will
> have a separate chapter for each adapter. Each adapter chapter will have a
> getting started and a reference/developer guide. There's also need for the
> relevant api docs in whatever format is most popular for a specific language
> * Examples - not sure where these will live. Maybe all examples for all
> adapters are in one repo
>
> Any changes to the above has to be raised. If you really want to discuss
> that then send a generic message to keycloak-dev list, basically don't
> include NodeJS in the title ;).
>
> On 11 April 2016 at 20:27, Lance Ball <lball at redhat.com> wrote:
>
>> I agree that keeping version numbers consistent might be questionable.
>> There is the big bump as Bruno notes, but also the npm modules need to be
>> able to publish in the absence of a keycloak release in the event that
>> there are bugs which need to be addressed in an adapter but not in keycloak
>> itself - e.g. https://issues.jboss.org/browse/KEYCLOAK-2798.
>>
>> Lance
>>
>> On Mon, Apr 11, 2016 at 2:21 PM, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>>
>>> +1 for consistency and release dates. But I'd keep the release version
>>> independent, move from 0.0.16 to 1.9.2 for example, is a huge bump.
>>>
>>> On Mon, Apr 11, 2016 at 1:43 PM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> We discussed this at the f2f and I believe we should keep it consistent
>>>> across all adapters.
>>>>
>>>> The decision was to have all adapters released when the server is
>>>> released and they will have the same version numbers. We will also make
>>>> sure release notes mark which adapters have changed and also which are
>>>> required to update (either due to compatibility changes or security related
>>>> fixes).
>>>>
>>>> So I'd like the ability to release nodejs adapters at the same time I
>>>> do the release of the server.
>>>>
>>>> We can certainly discuss changes to the above, but it should be
>>>> consistent for all our adapters.
>>>> On 11 Apr 2016 17:09, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>>>>
>>>> Good morning,
>>>>
>>>> Today I was chatting with Lance about the release cadence for Node.js
>>>> adapters.
>>>>
>>>> My initial idea was to release the adapters at exactly the same release
>>>> dates as the official Keycloak release in order to guarantee compatibility.
>>>> For critical/urgent patches, we just release those modules based on our
>>>> judgment.
>>>>
>>>> Lance would like more flexibility between those releases. For example,
>>>> release npm modules before the official release for situations where a user
>>>> wants some new capability that is perhaps unrelated to changes in KC
>>>> itself e.g. a move to promises.
>>>>
>>>> I don't have any problems on keeping Node.js adapters' release
>>>> independent from official KC release, but would like to hear more opinions
>>>> about it.
>>>>
>>>> --
>>>>
>>>>
>>>> -
>>>> abstractj
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/dfc59097/attachment.html 

From sthorger at redhat.com  Tue Apr 12 09:37:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Apr 2016 15:37:21 +0200
Subject: [keycloak-dev] Node.js adapter releases
In-Reply-To: <CALD3Fd0Bp1LC+wz1bOh5H2ix7=2FZeM-96Tba47r3=GJeofSJw@mail.gmail.com>
References: <CAM5SUC45=ztbb27xLvrmDNCqtFTp7G+pc3ggRuRDAXvfszO62Q@mail.gmail.com>
	<CAJgngAfUXVV37HnvcVmO7=kncm09=wD0x8nhs27s_T=4LMLTsA@mail.gmail.com>
	<CAJgngAcbV4AUobGuX6j=Gxo9F8zNzBNfQ4+4yGa-WqaZ6=BEkg@mail.gmail.com>
	<CAJgngAcOiZwisSpum2cGT1x-pJGmdxxo-oGhpVL8G=-fU5Wy0A@mail.gmail.com>
	<CAJgngAedFWi9-DSSHkm-7F+3s0aFpniDtgnwpAVPDKbLhY9t2g@mail.gmail.com>
	<CAJgngAfbmax_c0F91YdV=srBx+2PxoQNQmd9MqCCE5WUScSKjA@mail.gmail.com>
	<CAM5SUC7qTA9Kx2WhQntg+3x6sSQw4vn-sM30X8+S8L7bMa2n4w@mail.gmail.com>
	<CABRDmifsfQnkSu-mdwzurt+hZG-dNa4PO3jrUxsKgaC3_yQVvw@mail.gmail.com>
	<CAJgngAcJHSbiDa02XX+AkiS+6HHnSqe-nQ_-uiLPq4SmLH+4qQ@mail.gmail.com>
	<CALD3Fd0Bp1LC+wz1bOh5H2ix7=2FZeM-96Tba47r3=GJeofSJw@mail.gmail.com>
Message-ID: <CAJgngAcwaFK8avkfHqVapendB2ngHrVJLo6On0T1m4xnVA1dVw@mail.gmail.com>

On 12 April 2016 at 15:24, Luke Holmquist <lholmqui at redhat.com> wrote:

>
>
> On Tue, Apr 12, 2016 at 12:29 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Having the same version makes it much easier for people to grab a version
>> they know works with a specific Keycloak version. It also makes it simpler
>> when we release.
>>
>> Keycloak has a 6 week release cadence
>>
> While this probably works most of the time,  i'm wondering what happens,
> for example, if in the node.js adapter there is a security vulnerability in
> one of the dependent packages that is discovered a couple days after a
> release,  would you then need to create a new release of all of Keycloak?
>  that is fine, i'm just wondering if thats what would happen since that
> could be a real possibility.  so for an issue like this:
> https://issues.jboss.org/browse/KEYCLOAK-2798. a full keycloak release
> would need to happen then?
>

It depends on the severity of the vulnerability. If it's critical a minor
release will be done (of everything) asap. Bugs and improvements will not
be pushed out more frequently than 6 weeks.


>
> *everything i said above only applies if that node adapter is a full class
> citizen,  obviously "community" things are different *
>

The aim is to make the nodejs adapter a full class citizen soon :)


>
>
>
>> and adapters shouldn't be released more frequently. Rather they should be
>> released at the same time as the server and by the same release job in
>> Jenkins.
>>
>> To become a first class citizen an adapter has to:
>>
>> * Release at same time as Keycloak server (every ~6 weeks). We test and
>> release everything as a bundle and don't have the resources to maintain
>> separate release cycles. I also want all adapters to be consistent here.
>> * Documentation - we're going to have a adapters documentation, it will
>> have a separate chapter for each adapter. Each adapter chapter will have a
>> getting started and a reference/developer guide. There's also need for the
>> relevant api docs in whatever format is most popular for a specific language
>> * Examples - not sure where these will live. Maybe all examples for all
>> adapters are in one repo
>>
>> Any changes to the above has to be raised. If you really want to discuss
>> that then send a generic message to keycloak-dev list, basically don't
>> include NodeJS in the title ;).
>>
>> On 11 April 2016 at 20:27, Lance Ball <lball at redhat.com> wrote:
>>
>>> I agree that keeping version numbers consistent might be questionable.
>>> There is the big bump as Bruno notes, but also the npm modules need to be
>>> able to publish in the absence of a keycloak release in the event that
>>> there are bugs which need to be addressed in an adapter but not in keycloak
>>> itself - e.g. https://issues.jboss.org/browse/KEYCLOAK-2798.
>>>
>>> Lance
>>>
>>> On Mon, Apr 11, 2016 at 2:21 PM, Bruno Oliveira <bruno at abstractj.org>
>>> wrote:
>>>
>>>> +1 for consistency and release dates. But I'd keep the release version
>>>> independent, move from 0.0.16 to 1.9.2 for example, is a huge bump.
>>>>
>>>> On Mon, Apr 11, 2016 at 1:43 PM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> We discussed this at the f2f and I believe we should keep it
>>>>> consistent across all adapters.
>>>>>
>>>>> The decision was to have all adapters released when the server is
>>>>> released and they will have the same version numbers. We will also make
>>>>> sure release notes mark which adapters have changed and also which are
>>>>> required to update (either due to compatibility changes or security related
>>>>> fixes).
>>>>>
>>>>> So I'd like the ability to release nodejs adapters at the same time I
>>>>> do the release of the server.
>>>>>
>>>>> We can certainly discuss changes to the above, but it should be
>>>>> consistent for all our adapters.
>>>>> On 11 Apr 2016 17:09, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>>>>>
>>>>> Good morning,
>>>>>
>>>>> Today I was chatting with Lance about the release cadence for Node.js
>>>>> adapters.
>>>>>
>>>>> My initial idea was to release the adapters at exactly the same
>>>>> release dates as the official Keycloak release in order to guarantee
>>>>> compatibility. For critical/urgent patches, we just release those modules
>>>>> based on our judgment.
>>>>>
>>>>> Lance would like more flexibility between those releases. For example,
>>>>> release npm modules before the official release for situations where a user
>>>>> wants some new capability that is perhaps unrelated to changes in KC
>>>>> itself e.g. a move to promises.
>>>>>
>>>>> I don't have any problems on keeping Node.js adapters' release
>>>>> independent from official KC release, but would like to hear more opinions
>>>>> about it.
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> -
>>>>> abstractj
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/a75f9c3a/attachment-0001.html 

From lball at redhat.com  Tue Apr 12 10:06:22 2016
From: lball at redhat.com (Lance Ball)
Date: Tue, 12 Apr 2016 10:06:22 -0400
Subject: [keycloak-dev] Node.js adapter releases
In-Reply-To: <CAJgngAcwaFK8avkfHqVapendB2ngHrVJLo6On0T1m4xnVA1dVw@mail.gmail.com>
References: <CAM5SUC45=ztbb27xLvrmDNCqtFTp7G+pc3ggRuRDAXvfszO62Q@mail.gmail.com>
	<CAJgngAfUXVV37HnvcVmO7=kncm09=wD0x8nhs27s_T=4LMLTsA@mail.gmail.com>
	<CAJgngAcbV4AUobGuX6j=Gxo9F8zNzBNfQ4+4yGa-WqaZ6=BEkg@mail.gmail.com>
	<CAJgngAcOiZwisSpum2cGT1x-pJGmdxxo-oGhpVL8G=-fU5Wy0A@mail.gmail.com>
	<CAJgngAedFWi9-DSSHkm-7F+3s0aFpniDtgnwpAVPDKbLhY9t2g@mail.gmail.com>
	<CAJgngAfbmax_c0F91YdV=srBx+2PxoQNQmd9MqCCE5WUScSKjA@mail.gmail.com>
	<CAM5SUC7qTA9Kx2WhQntg+3x6sSQw4vn-sM30X8+S8L7bMa2n4w@mail.gmail.com>
	<CABRDmifsfQnkSu-mdwzurt+hZG-dNa4PO3jrUxsKgaC3_yQVvw@mail.gmail.com>
	<CAJgngAcJHSbiDa02XX+AkiS+6HHnSqe-nQ_-uiLPq4SmLH+4qQ@mail.gmail.com>
	<CALD3Fd0Bp1LC+wz1bOh5H2ix7=2FZeM-96Tba47r3=GJeofSJw@mail.gmail.com>
	<CAJgngAcwaFK8avkfHqVapendB2ngHrVJLo6On0T1m4xnVA1dVw@mail.gmail.com>
Message-ID: <CABRDmic3XKN0emvhWB1eKuNGkpQ0X-zBy=oBup9a3RYj80pE6Q@mail.gmail.com>

On Tue, Apr 12, 2016 at 9:37 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

>
> It depends on the severity of the vulnerability. If it's critical a minor
> release will be done (of everything) asap. Bugs and improvements will not
> be pushed out more frequently than 6 weeks.
>

Which, I suppose, is a good argument for using as few 3rd party modules as
possible. :)

Lance

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/872d73f6/attachment.html 

From bburke at redhat.com  Tue Apr 12 10:55:00 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 12 Apr 2016 10:55:00 -0400
Subject: [keycloak-dev] Documentation subjects - need feedback
Message-ID: <570D0C44.6010907@redhat.com>

Created a wiki:

https://github.com/keycloak/keycloak/wiki/Docs

Please add things you want covered that are weak or non-existent in 
documentation.  I'll be going through the email list as I know there 
were a number of threads on this stuff too.  I'll post an outline 
sometime next week after we have a few internal meetings on the subject.

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


From bruno at abstractj.org  Tue Apr 12 11:03:20 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 12 Apr 2016 15:03:20 +0000
Subject: [keycloak-dev] Bug in UI?
In-Reply-To: <CAMJaV9mo13KS+HVFyJzcmxcC0noPs-yDwkvxDJZaSjUT7o+6XA@mail.gmail.com>
References: <CAMJaV9mo13KS+HVFyJzcmxcC0noPs-yDwkvxDJZaSjUT7o+6XA@mail.gmail.com>
Message-ID: <CAM5SUC6MHX2Anrof0s6VyD8cED6tBXnq8Jhx5n6aONpDGRW9tA@mail.gmail.com>

Hi Guus, everything is working here for me. Maybe you should try it against
the latest changes on master?

On Tue, Apr 12, 2016 at 7:10 AM Guus der Kinderen <
guus.der.kinderen at gmail.com> wrote:

> Hi,
>
> I did not try to reproduce this on master branch, but got it twice now on
> 1.9.x. The branch HEAD is commit b01f522acea6b6c5c6f487dc626a24ca928da77d
>
> After I build the distribution...
>
> $ mvn clean install -DskipTests -Pdistribution
>
>
> ... extract the distribution ...
>
> $ cd /distribution/server-dist/target/
> $ tar zxvf keycloak-1.9.2.Final-SNAPSHOT.tar.gz
>
>
> ... and start a standalone instance ...
>
> $ cd /keycloak-1.9.2.Final-SNAPSHOT/bin
> $ ./standalone.sh
>
> ... open the webpage at http://localhost:8080/auth
> ... create a new user
> ... login to the administration console with that user
> ... go to the list of clients
> ... and open (or click 'edit') on any of the clients
>
> Then the webpage that I'm looking at appears to be broken. I'm looking at
> the template itself, I think.
>
> Is this me, or can someone reproduce this?
>
>  - Guus
> _______________________________________________
> 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/20160412/b0c7e74a/attachment.html 

From guus.der.kinderen at gmail.com  Tue Apr 12 11:12:06 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Tue, 12 Apr 2016 17:12:06 +0200
Subject: [keycloak-dev] Bug in UI?
In-Reply-To: <CAM5SUC6MHX2Anrof0s6VyD8cED6tBXnq8Jhx5n6aONpDGRW9tA@mail.gmail.com>
References: <CAMJaV9mo13KS+HVFyJzcmxcC0noPs-yDwkvxDJZaSjUT7o+6XA@mail.gmail.com>
	<CAM5SUC6MHX2Anrof0s6VyD8cED6tBXnq8Jhx5n6aONpDGRW9tA@mail.gmail.com>
Message-ID: <CAMJaV9krMEeLt-0P=CjB+XA86fQKrbcvr4sjvkymupVa9SVzbw@mail.gmail.com>

Thanks for the feedback. I didn't try master yet, because I will be
deploying the upcoming 1.9.2 (master is currently at 2.0.0).

 - Guus

On 12 April 2016 at 17:03, Bruno Oliveira <bruno at abstractj.org> wrote:

> Hi Guus, everything is working here for me. Maybe you should try it
> against the latest changes on master?
>
> On Tue, Apr 12, 2016 at 7:10 AM Guus der Kinderen <
> guus.der.kinderen at gmail.com> wrote:
>
>> Hi,
>>
>> I did not try to reproduce this on master branch, but got it twice now on
>> 1.9.x. The branch HEAD is commit b01f522acea6b6c5c6f487dc626a24ca928da77d
>>
>> After I build the distribution...
>>
>> $ mvn clean install -DskipTests -Pdistribution
>>
>>
>> ... extract the distribution ...
>>
>> $ cd /distribution/server-dist/target/
>> $ tar zxvf keycloak-1.9.2.Final-SNAPSHOT.tar.gz
>>
>>
>> ... and start a standalone instance ...
>>
>> $ cd /keycloak-1.9.2.Final-SNAPSHOT/bin
>> $ ./standalone.sh
>>
>> ... open the webpage at http://localhost:8080/auth
>> ... create a new user
>> ... login to the administration console with that user
>> ... go to the list of clients
>> ... and open (or click 'edit') on any of the clients
>>
>> Then the webpage that I'm looking at appears to be broken. I'm looking at
>> the template itself, I think.
>>
>> Is this me, or can someone reproduce this?
>>
>>  - Guus
>> _______________________________________________
>> 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/20160412/c4fc6f82/attachment.html 

From bburke at redhat.com  Tue Apr 12 11:21:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 12 Apr 2016 11:21:49 -0400
Subject: [keycloak-dev] [keycloak-user] Documentation subjects - need
	feedback
In-Reply-To: <CAMu7ToqyCuOWBktKjx5QWD_vyK8w5WgpXEh0WVQxzNF5UKUncw@mail.gmail.com>
References: <570D0C44.6010907@redhat.com>
	<CAMu7ToqyCuOWBktKjx5QWD_vyK8w5WgpXEh0WVQxzNF5UKUncw@mail.gmail.com>
Message-ID: <570D128D.2010906@redhat.com>

Not sure what you mean by entitlements.  User role mappings is about all 
we got.  Please edit the Wiki directly.

On 4/12/2016 11:06 AM, Lars Noldan wrote:
> I'd love more documentation about how entitlements are being handled 
> by keycloak users, and best practices for configuring the same.
>
> On Tue, Apr 12, 2016 at 9:55 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Created a wiki:
>
>     https://github.com/keycloak/keycloak/wiki/Docs
>
>     Please add things you want covered that are weak or non-existent in
>     documentation.  I'll be going through the email list as I know there
>     were a number of threads on this stuff too.  I'll post an outline
>     sometime next week after we have a few internal meetings on the
>     subject.
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160412/2a630b18/attachment.html 

From lball at redhat.com  Tue Apr 12 13:25:11 2016
From: lball at redhat.com (Lance Ball)
Date: Tue, 12 Apr 2016 13:25:11 -0400
Subject: [keycloak-dev] Adapter Versioning
Message-ID: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>

Hi all

I've been emailing with Stian about versioning in the "Node.js adapter
releases" thread, but as he pointed out, some of my concerns are broader
than just Node.js and so I am broadening the conversation a bit.

Background: I am working as part of a Node.js RHT "middleware" team to,
among other things, contribute towards the development of Node.js modules
for our existing JBoss technologies. As part of this, we're doing what we
can for the Keycloak Node.js pieces.

As it stands now, I understand that versioning of adapters must remain in
lockstep with Keycloak core. I understand the motivation for this, but want
to push back on this just a little bit, and open it up for discussion.

I see a couple of scenarios where this is potentially problematic. I am
using Node.js and NPM here, but I think the concerns should apply to any
adapter that is part of an ecosystem outside of Java.

1) There is a security flaw in some 3rd party dependency of the adapter,
discovered the day of a Keycloak core release. This renders the "latest"
version of an adapter useless until a new Keycloak server is released. I
understand that the release cadence is anticipated to be approximately
every 6 weeks (which is laudable), but still that's > 1 month that users
have to wait for a security fix.

2) There is no change in the adapter between releases of Keycloak server.
In this case, it's not necessarily a problem to release a new adapter
version, but it seems noisy and pointless if the bits are exactly the same.

When we look at version numbers, they are typically MAJOR.MINOR.PATCH with
possibly a pre-release suffix like -Alpha1. I would like to discuss the
possibility for adapters to issue patch level releases independent of a
server release. This would allow for MAJOR.MINOR versions to remain
consistent so to communicate compatibility with a given Keycloak server
version. But would provide flexibility for adapters to deal with both
issues noted above.

And just for the sake of argument, let's look at a hypothetical situation
where Keycloak is baptized a Product, and the release cadence slows down
significantly to every 12-18 months. What if a major security flaw is
discovered in an adapter? Should this trigger a new release of Keycloak
server itself? Would it not be better to allow the adapter to issue a patch
level release instead?

If you've read this far - thanks! Looking forward to your thoughts.

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

From bruno at abstractj.org  Tue Apr 12 15:54:43 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 12 Apr 2016 19:54:43 +0000
Subject: [keycloak-dev] Adapter Versioning
In-Reply-To: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
References: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
Message-ID: <CAM5SUC4ky428vtvKXxvTfQLMdExDLEb8Y7zpZ12e2OCqF4dPYQ@mail.gmail.com>

On Tue, Apr 12, 2016 at 2:25 PM Lance Ball <lball at redhat.com> wrote:

> Hi all
>
> I've been emailing with Stian about versioning in the "Node.js adapter
> releases" thread, but as he pointed out, some of my concerns are broader
> than just Node.js and so I am broadening the conversation a bit.
>
> Background: I am working as part of a Node.js RHT "middleware" team to,
> among other things, contribute towards the development of Node.js modules
> for our existing JBoss technologies. As part of this, we're doing what we
> can for the Keycloak Node.js pieces.
>
> As it stands now, I understand that versioning of adapters must remain in
> lockstep with Keycloak core. I understand the motivation for this, but want
> to push back on this just a little bit, and open it up for discussion.
>
> I see a couple of scenarios where this is potentially problematic. I am
> using Node.js and NPM here, but I think the concerns should apply to any
> adapter that is part of an ecosystem outside of Java.
>
> 1) There is a security flaw in some 3rd party dependency of the adapter,
> discovered the day of a Keycloak core release. This renders the "latest"
> version of an adapter useless until a new Keycloak server is released. I
> understand that the release cadence is anticipated to be approximately
> every 6 weeks (which is laudable), but still that's > 1 month that users
> have to wait for a security fix.
>


In my opinion it depends how critical and exploitable is the vulnerability.
For critical updates, I'd say that the adapter should be release ASAP and
the patch number increased and released. For example: vulnerability found
at 0.0.16 we just bump it up to 0.0.17 and release.


>
> 2) There is no change in the adapter between releases of Keycloak server.
> In this case, it's not necessarily a problem to release a new adapter
> version, but it seems noisy and pointless if the bits are exactly the same.
>
> When we look at version numbers, they are typically MAJOR.MINOR.PATCH with
> possibly a pre-release suffix like -Alpha1. I would like to discuss the
> possibility for adapters to issue patch level releases independent of a
> server release. This would allow for MAJOR.MINOR versions to remain
> consistent so to communicate compatibility with a given Keycloak server
> version. But would provide flexibility for adapters to deal with both
> issues noted above.
>

I'm +1 on keeping independent version numbers from the server and state
something like connect-keycloak v0.0.17 is compatible with Keycloak server
1.9.2.Final for example. But I'm -1 on independent release dates ? unless
we have a critical security fix.

If we release whenever we want the adapters, would be hard to test, because
we don't have bandwith for it. I see as something which could become out of
control like v0.0.15, v0.0.16, v0.0.17 is compatible with KC 1.9.2, but
v0.0.18 only works with KC 2.0.x.

>
> And just for the sake of argument, let's look at a hypothetical situation
> where Keycloak is baptized a Product, and the release cadence slows down
> significantly to every 12-18 months. What if a major security flaw is
> discovered in an adapter? Should this trigger a new release of Keycloak
> server itself? Would it not be better to allow the adapter to issue a patch
> level release instead?
>

+1 for just the adapter issue a patch level release.

tl;dr my personal opinion is (anything that I'm going to say here can be
innacurate, because I don't have the whole context about the conversations
during the F2F):

- Adapters should be released on exactly the same dates as the server (with
one single exception, critical security fixes)
- The version number should be independent, in this way we state something
like Node.js adapters version 0.0.17 are fully compatible with KC 1.9.x.


>
> If you've read this far - thanks! Looking forward to your thoughts.
>
> Lance
>
> _______________________________________________
> 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/20160412/781ba9a3/attachment.html 

From sthorger at redhat.com  Wed Apr 13 00:36:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 06:36:16 +0200
Subject: [keycloak-dev] Adapter Versioning
In-Reply-To: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
References: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
Message-ID: <CAJgngAecnFvfq-bRvGQ1ikvpNcJnddHphAqsLYxFyPNqKacO+w@mail.gmail.com>

On 12 April 2016 at 19:25, Lance Ball <lball at redhat.com> wrote:

> Hi all
>
> I've been emailing with Stian about versioning in the "Node.js adapter
> releases" thread, but as he pointed out, some of my concerns are broader
> than just Node.js and so I am broadening the conversation a bit.
>
> Background: I am working as part of a Node.js RHT "middleware" team to,
> among other things, contribute towards the development of Node.js modules
> for our existing JBoss technologies. As part of this, we're doing what we
> can for the Keycloak Node.js pieces.
>
> As it stands now, I understand that versioning of adapters must remain in
> lockstep with Keycloak core. I understand the motivation for this, but want
> to push back on this just a little bit, and open it up for discussion.
>
> I see a couple of scenarios where this is potentially problematic. I am
> using Node.js and NPM here, but I think the concerns should apply to any
> adapter that is part of an ecosystem outside of Java.
>
> 1) There is a security flaw in some 3rd party dependency of the adapter,
> discovered the day of a Keycloak core release. This renders the "latest"
> version of an adapter useless until a new Keycloak server is released. I
> understand that the release cadence is anticipated to be approximately
> every 6 weeks (which is laudable), but still that's > 1 month that users
> have to wait for a security fix.
>

Non-issue as we will push out a release for a critical security fix as soon
as possible. Having a single release makes it actually easier to do.


>
> 2) There is no change in the adapter between releases of Keycloak server.
> In this case, it's not necessarily a problem to release a new adapter
> version, but it seems noisy and pointless if the bits are exactly the same.
>

The plan is to have release notes that cover which adapters have changed
and which are required to upgrade (either because backwards compatibility
is broken with the server or due to a security fix)


>
> When we look at version numbers, they are typically MAJOR.MINOR.PATCH with
> possibly a pre-release suffix like -Alpha1. I would like to discuss the
> possibility for adapters to issue patch level releases independent of a
> server release. This would allow for MAJOR.MINOR versions to remain
> consistent so to communicate compatibility with a given Keycloak server
> version. But would provide flexibility for adapters to deal with both
> issues noted above.
>

> And just for the sake of argument, let's look at a hypothetical situation
> where Keycloak is baptized a Product, and the release cadence slows down
> significantly to every 12-18 months. What if a major security flaw is
> discovered in an adapter? Should this trigger a new release of Keycloak
> server itself? Would it not be better to allow the adapter to issue a patch
> level release instead?
>

It won't and Keycloak is already becoming a product. Release cadence is 6
weeks in community.


>
> If you've read this far - thanks! Looking forward to your thoughts.
>
> Lance
>
>
> _______________________________________________
> 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/20160413/9f43f216/attachment.html 

From sthorger at redhat.com  Wed Apr 13 00:41:26 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 06:41:26 +0200
Subject: [keycloak-dev] Adapter Versioning
In-Reply-To: <CAM5SUC4ky428vtvKXxvTfQLMdExDLEb8Y7zpZ12e2OCqF4dPYQ@mail.gmail.com>
References: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
	<CAM5SUC4ky428vtvKXxvTfQLMdExDLEb8Y7zpZ12e2OCqF4dPYQ@mail.gmail.com>
Message-ID: <CAJgngAdVUbkf_oZ9zQToyfqpuOqAvqXpEHHhVtBsZtY13_jiNw@mail.gmail.com>

All existing adapters follow:
* Release at the same time as server (by the same Jenkins job)
* Same version as the server

Then the improvements we discussed at F2F are:
* Add note to release notes to show what adapters are required to update
* Add a separate adapters guide, with a chapter for each adapter.

That is the simplest and cleanest solution IMO. Further, just to point out
that I want all official Keycloak adapters to follow the same process.

On 12 April 2016 at 21:54, Bruno Oliveira <bruno at abstractj.org> wrote:

> On Tue, Apr 12, 2016 at 2:25 PM Lance Ball <lball at redhat.com> wrote:
>
>> Hi all
>>
>> I've been emailing with Stian about versioning in the "Node.js adapter
>> releases" thread, but as he pointed out, some of my concerns are broader
>> than just Node.js and so I am broadening the conversation a bit.
>>
>> Background: I am working as part of a Node.js RHT "middleware" team to,
>> among other things, contribute towards the development of Node.js modules
>> for our existing JBoss technologies. As part of this, we're doing what we
>> can for the Keycloak Node.js pieces.
>>
>> As it stands now, I understand that versioning of adapters must remain in
>> lockstep with Keycloak core. I understand the motivation for this, but want
>> to push back on this just a little bit, and open it up for discussion.
>>
>> I see a couple of scenarios where this is potentially problematic. I am
>> using Node.js and NPM here, but I think the concerns should apply to any
>> adapter that is part of an ecosystem outside of Java.
>>
>> 1) There is a security flaw in some 3rd party dependency of the adapter,
>> discovered the day of a Keycloak core release. This renders the "latest"
>> version of an adapter useless until a new Keycloak server is released. I
>> understand that the release cadence is anticipated to be approximately
>> every 6 weeks (which is laudable), but still that's > 1 month that users
>> have to wait for a security fix.
>>
>
>
> In my opinion it depends how critical and exploitable is the
> vulnerability. For critical updates, I'd say that the adapter should be
> release ASAP and the patch number increased and released. For example:
> vulnerability found at 0.0.16 we just bump it up to 0.0.17 and release.
>
>
>>
>> 2) There is no change in the adapter between releases of Keycloak server.
>> In this case, it's not necessarily a problem to release a new adapter
>> version, but it seems noisy and pointless if the bits are exactly the same.
>>
>> When we look at version numbers, they are typically MAJOR.MINOR.PATCH
>> with possibly a pre-release suffix like -Alpha1. I would like to discuss
>> the possibility for adapters to issue patch level releases independent of a
>> server release. This would allow for MAJOR.MINOR versions to remain
>> consistent so to communicate compatibility with a given Keycloak server
>> version. But would provide flexibility for adapters to deal with both
>> issues noted above.
>>
>
> I'm +1 on keeping independent version numbers from the server and state
> something like connect-keycloak v0.0.17 is compatible with Keycloak server
> 1.9.2.Final for example. But I'm -1 on independent release dates ? unless
> we have a critical security fix.
>
> If we release whenever we want the adapters, would be hard to test,
> because we don't have bandwith for it. I see as something which could
> become out of control like v0.0.15, v0.0.16, v0.0.17 is compatible with KC
> 1.9.2, but v0.0.18 only works with KC 2.0.x.
>
>>
>> And just for the sake of argument, let's look at a hypothetical situation
>> where Keycloak is baptized a Product, and the release cadence slows down
>> significantly to every 12-18 months. What if a major security flaw is
>> discovered in an adapter? Should this trigger a new release of Keycloak
>> server itself? Would it not be better to allow the adapter to issue a patch
>> level release instead?
>>
>
> +1 for just the adapter issue a patch level release.
>
> tl;dr my personal opinion is (anything that I'm going to say here can be
> innacurate, because I don't have the whole context about the conversations
> during the F2F):
>
> - Adapters should be released on exactly the same dates as the server
> (with one single exception, critical security fixes)
>

They are actually going to be released by the same process.


> - The version number should be independent, in this way we state something
> like Node.js adapters version 0.0.17 are fully compatible with KC 1.9.x.
>

No, version is the same as the server. Having to install server 1.9.5, jee
adapter 1.8.7, javascript adapter 1.0.5 and nodejs adapter 0.5.0 is just
crazy.


>
>
>>
>> If you've read this far - thanks! Looking forward to your thoughts.
>>
>> Lance
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/2691bfb3/attachment-0001.html 

From sthorger at redhat.com  Wed Apr 13 04:01:17 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 10:01:17 +0200
Subject: [keycloak-dev] Preventing password managers from filling password
 fields on forms outside login
Message-ID: <CAJgngAcA2y6aG-YuUO8eLgoPsFX7M3Bb8JdEHBGSWU=FnZOoeg@mail.gmail.com>

Password managers are becoming increasingly naive when it comes to filling
a form with username/password. In fact Firefox's algorithm is as simple as:

* Is there a input type=text followed by input type=password then sure it's
a login form
* autocomplete=false let's ignore that, otherwise those pesky web
developers may stop us from filling username/password

Makes sense right? Well sure it does as long as it's an actual login form.
Problems comes when it's not, for example in Keycloak:

* Admin wants to reset user credentials - Firefox enters admins own password
* Admin wants to register a identity broker - Firefox enters admins
username/password as client id/secret
* User wants to register new user - Firefox enters previously used password
* This is the best one! When admin wants to configure a authenticator and
the config type is a string Firefox enters the password into the hidden
password input, then since the visible text field and the hidden password
field share the same model Angular copies the value from the hidden
password field to the text field and no the admins password is visible in
clear text. More details in KEYCLOAK-2804.

Awesome stuff! Every form with a password field must be a login form
right?!?

Solution is simple. If you create a form that has a input type=password
then add the following to the top of the form:

    <input type="text" readonly value="this is not a login form"
style="display: none;">
    <input type="password" readonly value="this is not a login form"
style="display: none;">

This will make the password manager assume does fields are the
username/password fields and since they are readonly it won't fill them.

Changes to Keycloak here https://github.com/keycloak/keycloak/pull/2600.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/7d283bfd/attachment.html 

From thomas.raehalme at aitiofinland.com  Wed Apr 13 04:07:20 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 13 Apr 2016 11:07:20 +0300
Subject: [keycloak-dev] robots.txt
Message-ID: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>

Hi!

What do you think of including robots.txt in the Keycloak distribution to
try to avoid Keycloak being indexed?

We had a nasty issue with BingPreview trying to load URLs and causing
one-time links to be invalidated.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/f6018197/attachment.html 

From sthorger at redhat.com  Wed Apr 13 04:11:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 10:11:02 +0200
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
Message-ID: <CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>

+1

How did it find one-time links?

On 13 April 2016 at 10:07, Thomas Raehalme <thomas.raehalme at aitiofinland.com
> wrote:

> Hi!
>
> What do you think of including robots.txt in the Keycloak distribution to
> try to avoid Keycloak being indexed?
>
> We had a nasty issue with BingPreview trying to load URLs and causing
> one-time links to be invalidated.
>
> Best regards,
> Thomas
>
> _______________________________________________
> 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/20160413/7e5045c4/attachment.html 

From thomas.raehalme at aitiofinland.com  Wed Apr 13 04:17:19 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 13 Apr 2016 11:17:19 +0300
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
Message-ID: <CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>

I think the user is running some Bing browser plugin or desktop application
which loads a page snapshot/preview of whatever links it finds in user
content.

I created KEYCLOAK-2810 to add robots.txt.
https://issues.jboss.org/browse/KEYCLOAK-2810

Best regards,
Thomas


On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> +1
>
> How did it find one-time links?
>
> On 13 April 2016 at 10:07, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> Hi!
>>
>> What do you think of including robots.txt in the Keycloak distribution to
>> try to avoid Keycloak being indexed?
>>
>> We had a nasty issue with BingPreview trying to load URLs and causing
>> one-time links to be invalidated.
>>
>> Best regards,
>> Thomas
>>
>> _______________________________________________
>> 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/20160413/95b27ca6/attachment.html 

From sthorger at redhat.com  Wed Apr 13 04:41:18 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 10:41:18 +0200
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
Message-ID: <CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>

Is it sufficient to add that to /auth/robots.txt?

On 13 April 2016 at 10:17, Thomas Raehalme <thomas.raehalme at aitiofinland.com
> wrote:

> I think the user is running some Bing browser plugin or desktop
> application which loads a page snapshot/preview of whatever links it finds
> in user content.
>
> I created KEYCLOAK-2810 to add robots.txt.
> https://issues.jboss.org/browse/KEYCLOAK-2810
>
> Best regards,
> Thomas
>
>
> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> +1
>>
>> How did it find one-time links?
>>
>> On 13 April 2016 at 10:07, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>>> Hi!
>>>
>>> What do you think of including robots.txt in the Keycloak distribution
>>> to try to avoid Keycloak being indexed?
>>>
>>> We had a nasty issue with BingPreview trying to load URLs and causing
>>> one-time links to be invalidated.
>>>
>>> Best regards,
>>> Thomas
>>>
>>> _______________________________________________
>>> 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/20160413/cb0f7220/attachment.html 

From thomas.raehalme at aitiofinland.com  Wed Apr 13 04:47:30 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 13 Apr 2016 11:47:30 +0300
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
	<CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
Message-ID: <CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>

I think it needs to be in the root folder.

Best regards,
Thomas

On Wed, Apr 13, 2016 at 11:41 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Is it sufficient to add that to /auth/robots.txt?
>
> On 13 April 2016 at 10:17, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> I think the user is running some Bing browser plugin or desktop
>> application which loads a page snapshot/preview of whatever links it finds
>> in user content.
>>
>> I created KEYCLOAK-2810 to add robots.txt.
>> https://issues.jboss.org/browse/KEYCLOAK-2810
>>
>> Best regards,
>> Thomas
>>
>>
>> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> +1
>>>
>>> How did it find one-time links?
>>>
>>> On 13 April 2016 at 10:07, Thomas Raehalme <
>>> thomas.raehalme at aitiofinland.com> wrote:
>>>
>>>> Hi!
>>>>
>>>> What do you think of including robots.txt in the Keycloak distribution
>>>> to try to avoid Keycloak being indexed?
>>>>
>>>> We had a nasty issue with BingPreview trying to load URLs and causing
>>>> one-time links to be invalidated.
>>>>
>>>> Best regards,
>>>> Thomas
>>>>
>>>> _______________________________________________
>>>> 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/20160413/acbdb8dd/attachment-0001.html 

From sthorger at redhat.com  Wed Apr 13 04:52:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 10:52:29 +0200
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
	<CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
	<CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>
Message-ID: <CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>

Maybe it should be /robots.txt and /auth/robots.txt. The first will cover
the case when Keycloak is exposed directly, while the latter when a reverse
proxy is used (for example auth.example.org --> kc-ip/auth).

On 13 April 2016 at 10:47, Thomas Raehalme <thomas.raehalme at aitiofinland.com
> wrote:

> I think it needs to be in the root folder.
>
> Best regards,
> Thomas
>
> On Wed, Apr 13, 2016 at 11:41 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Is it sufficient to add that to /auth/robots.txt?
>>
>> On 13 April 2016 at 10:17, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>>> I think the user is running some Bing browser plugin or desktop
>>> application which loads a page snapshot/preview of whatever links it finds
>>> in user content.
>>>
>>> I created KEYCLOAK-2810 to add robots.txt.
>>> https://issues.jboss.org/browse/KEYCLOAK-2810
>>>
>>> Best regards,
>>> Thomas
>>>
>>>
>>> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> How did it find one-time links?
>>>>
>>>> On 13 April 2016 at 10:07, Thomas Raehalme <
>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> What do you think of including robots.txt in the Keycloak distribution
>>>>> to try to avoid Keycloak being indexed?
>>>>>
>>>>> We had a nasty issue with BingPreview trying to load URLs and causing
>>>>> one-time links to be invalidated.
>>>>>
>>>>> Best regards,
>>>>> Thomas
>>>>>
>>>>> _______________________________________________
>>>>> 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/20160413/81dc29bc/attachment.html 

From thomas.raehalme at aitiofinland.com  Wed Apr 13 04:54:22 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 13 Apr 2016 11:54:22 +0300
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
	<CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
	<CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>
	<CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>
Message-ID: <CAPyAMoY_XUSqbX4zCZUu7FQK=os7hsHv80Uv+jH_57SCKkzpuQ@mail.gmail.com>

Do you mean that in the reverse proxy setup /auth is the visible root?

Best regards,
Thomas

On Wed, Apr 13, 2016 at 11:52 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Maybe it should be /robots.txt and /auth/robots.txt. The first will cover
> the case when Keycloak is exposed directly, while the latter when a reverse
> proxy is used (for example auth.example.org --> kc-ip/auth).
>
> On 13 April 2016 at 10:47, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> I think it needs to be in the root folder.
>>
>> Best regards,
>> Thomas
>>
>> On Wed, Apr 13, 2016 at 11:41 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Is it sufficient to add that to /auth/robots.txt?
>>>
>>> On 13 April 2016 at 10:17, Thomas Raehalme <
>>> thomas.raehalme at aitiofinland.com> wrote:
>>>
>>>> I think the user is running some Bing browser plugin or desktop
>>>> application which loads a page snapshot/preview of whatever links it finds
>>>> in user content.
>>>>
>>>> I created KEYCLOAK-2810 to add robots.txt.
>>>> https://issues.jboss.org/browse/KEYCLOAK-2810
>>>>
>>>> Best regards,
>>>> Thomas
>>>>
>>>>
>>>> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <sthorger at redhat.com
>>>> > wrote:
>>>>
>>>>> +1
>>>>>
>>>>> How did it find one-time links?
>>>>>
>>>>> On 13 April 2016 at 10:07, Thomas Raehalme <
>>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> What do you think of including robots.txt in the Keycloak
>>>>>> distribution to try to avoid Keycloak being indexed?
>>>>>>
>>>>>> We had a nasty issue with BingPreview trying to load URLs and causing
>>>>>> one-time links to be invalidated.
>>>>>>
>>>>>> Best regards,
>>>>>> Thomas
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20160413/7d4c296d/attachment.html 

From thomas.darimont at googlemail.com  Wed Apr 13 04:54:40 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 13 Apr 2016 10:54:40 +0200
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
	<CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
	<CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>
	<CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>
Message-ID: <CAK-7U1ggtkssjgS4NQuG5a5esHtz2dQ_LRrT6KjdDmO6CTavUg@mail.gmail.com>

Another option would be to use html META-tags to control robot behaviour.

http://www.metatags.info/meta_name_robots

Cheers,
Thomas

2016-04-13 10:52 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> Maybe it should be /robots.txt and /auth/robots.txt. The first will cover
> the case when Keycloak is exposed directly, while the latter when a reverse
> proxy is used (for example auth.example.org --> kc-ip/auth).
>
> On 13 April 2016 at 10:47, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> I think it needs to be in the root folder.
>>
>> Best regards,
>> Thomas
>>
>> On Wed, Apr 13, 2016 at 11:41 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Is it sufficient to add that to /auth/robots.txt?
>>>
>>> On 13 April 2016 at 10:17, Thomas Raehalme <
>>> thomas.raehalme at aitiofinland.com> wrote:
>>>
>>>> I think the user is running some Bing browser plugin or desktop
>>>> application which loads a page snapshot/preview of whatever links it finds
>>>> in user content.
>>>>
>>>> I created KEYCLOAK-2810 to add robots.txt.
>>>> https://issues.jboss.org/browse/KEYCLOAK-2810
>>>>
>>>> Best regards,
>>>> Thomas
>>>>
>>>>
>>>> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <sthorger at redhat.com
>>>> > wrote:
>>>>
>>>>> +1
>>>>>
>>>>> How did it find one-time links?
>>>>>
>>>>> On 13 April 2016 at 10:07, Thomas Raehalme <
>>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> What do you think of including robots.txt in the Keycloak
>>>>>> distribution to try to avoid Keycloak being indexed?
>>>>>>
>>>>>> We had a nasty issue with BingPreview trying to load URLs and causing
>>>>>> one-time links to be invalidated.
>>>>>>
>>>>>> Best regards,
>>>>>> Thomas
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/4e2efb53/attachment.html 

From sthorger at redhat.com  Wed Apr 13 04:56:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 10:56:37 +0200
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAPyAMoY_XUSqbX4zCZUu7FQK=os7hsHv80Uv+jH_57SCKkzpuQ@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
	<CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
	<CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>
	<CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>
	<CAPyAMoY_XUSqbX4zCZUu7FQK=os7hsHv80Uv+jH_57SCKkzpuQ@mail.gmail.com>
Message-ID: <CAJgngAe+H_KeWpsTsVXXWq=OZMPtLMQAWdSdWUrGrAUsn5ywKw@mail.gmail.com>

On 13 April 2016 at 10:54, Thomas Raehalme <thomas.raehalme at aitiofinland.com
> wrote:

> Do you mean that in the reverse proxy setup /auth is the visible root?
>

Yes


>
> Best regards,
> Thomas
>
> On Wed, Apr 13, 2016 at 11:52 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Maybe it should be /robots.txt and /auth/robots.txt. The first will cover
>> the case when Keycloak is exposed directly, while the latter when a reverse
>> proxy is used (for example auth.example.org --> kc-ip/auth).
>>
>> On 13 April 2016 at 10:47, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>>> I think it needs to be in the root folder.
>>>
>>> Best regards,
>>> Thomas
>>>
>>> On Wed, Apr 13, 2016 at 11:41 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Is it sufficient to add that to /auth/robots.txt?
>>>>
>>>> On 13 April 2016 at 10:17, Thomas Raehalme <
>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>
>>>>> I think the user is running some Bing browser plugin or desktop
>>>>> application which loads a page snapshot/preview of whatever links it finds
>>>>> in user content.
>>>>>
>>>>> I created KEYCLOAK-2810 to add robots.txt.
>>>>> https://issues.jboss.org/browse/KEYCLOAK-2810
>>>>>
>>>>> Best regards,
>>>>> Thomas
>>>>>
>>>>>
>>>>> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> How did it find one-time links?
>>>>>>
>>>>>> On 13 April 2016 at 10:07, Thomas Raehalme <
>>>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> What do you think of including robots.txt in the Keycloak
>>>>>>> distribution to try to avoid Keycloak being indexed?
>>>>>>>
>>>>>>> We had a nasty issue with BingPreview trying to load URLs and
>>>>>>> causing one-time links to be invalidated.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Thomas
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/20160413/06dbd762/attachment-0001.html 

From sthorger at redhat.com  Wed Apr 13 04:57:52 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 10:57:52 +0200
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAK-7U1ggtkssjgS4NQuG5a5esHtz2dQ_LRrT6KjdDmO6CTavUg@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
	<CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
	<CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>
	<CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>
	<CAK-7U1ggtkssjgS4NQuG5a5esHtz2dQ_LRrT6KjdDmO6CTavUg@mail.gmail.com>
Message-ID: <CAJgngAdMeCszSJ6oBEQJgeYvFhwcSK0PW95WeCHgwY_-bUEqgA@mail.gmail.com>

Should be easy enough to add. Just need to add to template.ftl for
login/account and index.ftl for admin.

On 13 April 2016 at 10:54, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Another option would be to use html META-tags to control robot behaviour.
>
> http://www.metatags.info/meta_name_robots
>
> Cheers,
> Thomas
>
> 2016-04-13 10:52 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> Maybe it should be /robots.txt and /auth/robots.txt. The first will cover
>> the case when Keycloak is exposed directly, while the latter when a reverse
>> proxy is used (for example auth.example.org --> kc-ip/auth).
>>
>> On 13 April 2016 at 10:47, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>>> I think it needs to be in the root folder.
>>>
>>> Best regards,
>>> Thomas
>>>
>>> On Wed, Apr 13, 2016 at 11:41 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Is it sufficient to add that to /auth/robots.txt?
>>>>
>>>> On 13 April 2016 at 10:17, Thomas Raehalme <
>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>
>>>>> I think the user is running some Bing browser plugin or desktop
>>>>> application which loads a page snapshot/preview of whatever links it finds
>>>>> in user content.
>>>>>
>>>>> I created KEYCLOAK-2810 to add robots.txt.
>>>>> https://issues.jboss.org/browse/KEYCLOAK-2810
>>>>>
>>>>> Best regards,
>>>>> Thomas
>>>>>
>>>>>
>>>>> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> How did it find one-time links?
>>>>>>
>>>>>> On 13 April 2016 at 10:07, Thomas Raehalme <
>>>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> What do you think of including robots.txt in the Keycloak
>>>>>>> distribution to try to avoid Keycloak being indexed?
>>>>>>>
>>>>>>> We had a nasty issue with BingPreview trying to load URLs and
>>>>>>> causing one-time links to be invalidated.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Thomas
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/305308d3/attachment.html 

From thomas.raehalme at aitiofinland.com  Wed Apr 13 04:59:16 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 13 Apr 2016 11:59:16 +0300
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAK-7U1ggtkssjgS4NQuG5a5esHtz2dQ_LRrT6KjdDmO6CTavUg@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
	<CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
	<CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>
	<CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>
	<CAK-7U1ggtkssjgS4NQuG5a5esHtz2dQ_LRrT6KjdDmO6CTavUg@mail.gmail.com>
Message-ID: <CAPyAMobSapromUH2-jML4PJ0V8sgxctgiQ+bhe1MXqf8Dzo_rQ@mail.gmail.com>

Yes, but then you'd need to make sure that every theme has them (including
user-defined themes).

Maybe we can do both?

Best regards,
Thomas


On Wed, Apr 13, 2016 at 11:54 AM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Another option would be to use html META-tags to control robot behaviour.
>
> http://www.metatags.info/meta_name_robots
>
> Cheers,
> Thomas
>
> 2016-04-13 10:52 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> Maybe it should be /robots.txt and /auth/robots.txt. The first will cover
>> the case when Keycloak is exposed directly, while the latter when a reverse
>> proxy is used (for example auth.example.org --> kc-ip/auth).
>>
>> On 13 April 2016 at 10:47, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>>> I think it needs to be in the root folder.
>>>
>>> Best regards,
>>> Thomas
>>>
>>> On Wed, Apr 13, 2016 at 11:41 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Is it sufficient to add that to /auth/robots.txt?
>>>>
>>>> On 13 April 2016 at 10:17, Thomas Raehalme <
>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>
>>>>> I think the user is running some Bing browser plugin or desktop
>>>>> application which loads a page snapshot/preview of whatever links it finds
>>>>> in user content.
>>>>>
>>>>> I created KEYCLOAK-2810 to add robots.txt.
>>>>> https://issues.jboss.org/browse/KEYCLOAK-2810
>>>>>
>>>>> Best regards,
>>>>> Thomas
>>>>>
>>>>>
>>>>> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> How did it find one-time links?
>>>>>>
>>>>>> On 13 April 2016 at 10:07, Thomas Raehalme <
>>>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> What do you think of including robots.txt in the Keycloak
>>>>>>> distribution to try to avoid Keycloak being indexed?
>>>>>>>
>>>>>>> We had a nasty issue with BingPreview trying to load URLs and
>>>>>>> causing one-time links to be invalidated.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Thomas
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/90056484/attachment.html 

From sthorger at redhat.com  Wed Apr 13 05:01:15 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 11:01:15 +0200
Subject: [keycloak-dev] robots.txt
In-Reply-To: <CAPyAMobSapromUH2-jML4PJ0V8sgxctgiQ+bhe1MXqf8Dzo_rQ@mail.gmail.com>
References: <CAPyAMoatXAwo54HCOH1XFuDt+qebPevfZW8MH0L0O4_Pe+kc=Q@mail.gmail.com>
	<CAJgngAeEszNjARK6Q5N=gJYy4ukVXTghpS8e-gt0L+t1SG8r4Q@mail.gmail.com>
	<CAPyAMob+Ak_rAehUtj7iXmTmOJMr_59WDsQR1-HoVVHvGZXHjQ@mail.gmail.com>
	<CAJgngAdKGssuBN-3g2Kvr+D3qj+9ChcQ9oaajEsXXfuRHsu6Hg@mail.gmail.com>
	<CAPyAMoa42Ymfoc2aD3v0DH_QEF3tJr9JBxB5wXmx7gcu0qGctA@mail.gmail.com>
	<CAJgngAeS0FjS94GY+mE4JadwDztxgjgmQDMX_hqALK_HKO4tzQ@mail.gmail.com>
	<CAK-7U1ggtkssjgS4NQuG5a5esHtz2dQ_LRrT6KjdDmO6CTavUg@mail.gmail.com>
	<CAPyAMobSapromUH2-jML4PJ0V8sgxctgiQ+bhe1MXqf8Dzo_rQ@mail.gmail.com>
Message-ID: <CAJgngAdMjZagGkpofLrMCpHKmJAiU+s+CGK3d3gAVyveF3oCmg@mail.gmail.com>

I'm happy with doing both as I can't see any harm in adding it.

On 13 April 2016 at 10:59, Thomas Raehalme <thomas.raehalme at aitiofinland.com
> wrote:

> Yes, but then you'd need to make sure that every theme has them (including
> user-defined themes).
>
> Maybe we can do both?
>
> Best regards,
> Thomas
>
>
> On Wed, Apr 13, 2016 at 11:54 AM, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Another option would be to use html META-tags to control robot behaviour.
>>
>> http://www.metatags.info/meta_name_robots
>>
>> Cheers,
>> Thomas
>>
>> 2016-04-13 10:52 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> Maybe it should be /robots.txt and /auth/robots.txt. The first will
>>> cover the case when Keycloak is exposed directly, while the latter when a
>>> reverse proxy is used (for example auth.example.org --> kc-ip/auth).
>>>
>>> On 13 April 2016 at 10:47, Thomas Raehalme <
>>> thomas.raehalme at aitiofinland.com> wrote:
>>>
>>>> I think it needs to be in the root folder.
>>>>
>>>> Best regards,
>>>> Thomas
>>>>
>>>> On Wed, Apr 13, 2016 at 11:41 AM, Stian Thorgersen <sthorger at redhat.com
>>>> > wrote:
>>>>
>>>>> Is it sufficient to add that to /auth/robots.txt?
>>>>>
>>>>> On 13 April 2016 at 10:17, Thomas Raehalme <
>>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>>
>>>>>> I think the user is running some Bing browser plugin or desktop
>>>>>> application which loads a page snapshot/preview of whatever links it finds
>>>>>> in user content.
>>>>>>
>>>>>> I created KEYCLOAK-2810 to add robots.txt.
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2810
>>>>>>
>>>>>> Best regards,
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 13, 2016 at 11:11 AM, Stian Thorgersen <
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> How did it find one-time links?
>>>>>>>
>>>>>>> On 13 April 2016 at 10:07, Thomas Raehalme <
>>>>>>> thomas.raehalme at aitiofinland.com> wrote:
>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> What do you think of including robots.txt in the Keycloak
>>>>>>>> distribution to try to avoid Keycloak being indexed?
>>>>>>>>
>>>>>>>> We had a nasty issue with BingPreview trying to load URLs and
>>>>>>>> causing one-time links to be invalidated.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/b7cc733c/attachment-0001.html 

From sthorger at redhat.com  Wed Apr 13 06:15:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 12:15:25 +0200
Subject: [keycloak-dev] Release testing
Message-ID: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>

We're ready to start testing for 1.9.2 release. Please get started going
through:

https://docs.google.com/spreadsheets/d/1C1nCxbjehFSMhf2dDzXeH1Q2AYsozQ5mcZkhpac6NOU

Everyone should know the drill by now, so I'm not going to list the steps
this time around.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/3492f929/attachment.html 

From guus.der.kinderen at gmail.com  Wed Apr 13 06:18:56 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Wed, 13 Apr 2016 12:18:56 +0200
Subject: [keycloak-dev] Release testing
In-Reply-To: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
References: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
Message-ID: <CAMJaV9mE8D+_drEjxkvrEYtvphTE+=BC4yQMiRDw3XBQZVEY_Q@mail.gmail.com>

That spreadsheet is not open to the public - so I don't know if this is
covered:
http://lists.jboss.org/pipermail/keycloak-dev/2016-April/006960.html

That's still an issue for me.

 - Guus

On 13 April 2016 at 12:15, Stian Thorgersen <sthorger at redhat.com> wrote:

> We're ready to start testing for 1.9.2 release. Please get started going
> through:
>
>
> https://docs.google.com/spreadsheets/d/1C1nCxbjehFSMhf2dDzXeH1Q2AYsozQ5mcZkhpac6NOU
>
> Everyone should know the drill by now, so I'm not going to list the steps
> this time around.
>
> _______________________________________________
> 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/20160413/e12c6ddc/attachment.html 

From bburke at redhat.com  Wed Apr 13 07:21:31 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Apr 2016 07:21:31 -0400
Subject: [keycloak-dev] Release testing
In-Reply-To: <CAMJaV9mE8D+_drEjxkvrEYtvphTE+=BC4yQMiRDw3XBQZVEY_Q@mail.gmail.com>
References: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
	<CAMJaV9mE8D+_drEjxkvrEYtvphTE+=BC4yQMiRDw3XBQZVEY_Q@mail.gmail.com>
Message-ID: <570E2BBB.9020802@redhat.com>

I saw this too.  Looks like the latest 1.9.x fixed it.

On 4/13/2016 6:18 AM, Guus der Kinderen wrote:
> That spreadsheet is not open to the public - so I don't know if this 
> is covered: 
> http://lists.jboss.org/pipermail/keycloak-dev/2016-April/006960.html
>
> That's still an issue for me.
>
>  - Guus
>
> On 13 April 2016 at 12:15, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     We're ready to start testing for 1.9.2 release. Please get started
>     going through:
>
>     https://docs.google.com/spreadsheets/d/1C1nCxbjehFSMhf2dDzXeH1Q2AYsozQ5mcZkhpac6NOU
>
>     Everyone should know the drill by now, so I'm not going to list
>     the steps this time around.
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Wed Apr 13 07:32:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 13:32:43 +0200
Subject: [keycloak-dev] Release testing
In-Reply-To: <CAMJaV9mE8D+_drEjxkvrEYtvphTE+=BC4yQMiRDw3XBQZVEY_Q@mail.gmail.com>
References: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
	<CAMJaV9mE8D+_drEjxkvrEYtvphTE+=BC4yQMiRDw3XBQZVEY_Q@mail.gmail.com>
Message-ID: <CAJgngAeMhwt6oQ8bRLDMQXE1djAPy=PEbXD06zoOAoZ6Dw7Gmg@mail.gmail.com>

Tried to reproduce in 1.9.x now, but couldn't. What role mappings did you
give the new user?

On 13 April 2016 at 12:18, Guus der Kinderen <guus.der.kinderen at gmail.com>
wrote:

> That spreadsheet is not open to the public - so I don't know if this is
> covered:
> http://lists.jboss.org/pipermail/keycloak-dev/2016-April/006960.html
>
> That's still an issue for me.
>
>  - Guus
>
> On 13 April 2016 at 12:15, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> We're ready to start testing for 1.9.2 release. Please get started going
>> through:
>>
>>
>> https://docs.google.com/spreadsheets/d/1C1nCxbjehFSMhf2dDzXeH1Q2AYsozQ5mcZkhpac6NOU
>>
>> Everyone should know the drill by now, so I'm not going to list the steps
>> this time around.
>>
>> _______________________________________________
>> 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/20160413/6a47f9a1/attachment.html 

From bruno at abstractj.org  Wed Apr 13 07:37:37 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 13 Apr 2016 11:37:37 +0000
Subject: [keycloak-dev] Adapter Versioning
In-Reply-To: <CAJgngAdVUbkf_oZ9zQToyfqpuOqAvqXpEHHhVtBsZtY13_jiNw@mail.gmail.com>
References: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
	<CAM5SUC4ky428vtvKXxvTfQLMdExDLEb8Y7zpZ12e2OCqF4dPYQ@mail.gmail.com>
	<CAJgngAdVUbkf_oZ9zQToyfqpuOqAvqXpEHHhVtBsZtY13_jiNw@mail.gmail.com>
Message-ID: <CAM5SUC6NGRRkyx7FHqF+OkQ-B2ywnPv4nUXLEB3FF07Ps9_p0g@mail.gmail.com>

On Wed, Apr 13, 2016 at 1:41 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> All existing adapters follow:
> * Release at the same time as server (by the same Jenkins job)
> * Same version as the server
>
> Then the improvements we discussed at F2F are:
> * Add note to release notes to show what adapters are required to update
> * Add a separate adapters guide, with a chapter for each adapter.
>
> That is the simplest and cleanest solution IMO. Further, just to point out
> that I want all official Keycloak adapters to follow the same process.
>
> On 12 April 2016 at 21:54, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> On Tue, Apr 12, 2016 at 2:25 PM Lance Ball <lball at redhat.com> wrote:
>>
>>> Hi all
>>>
>>> I've been emailing with Stian about versioning in the "Node.js adapter
>>> releases" thread, but as he pointed out, some of my concerns are broader
>>> than just Node.js and so I am broadening the conversation a bit.
>>>
>>> Background: I am working as part of a Node.js RHT "middleware" team to,
>>> among other things, contribute towards the development of Node.js modules
>>> for our existing JBoss technologies. As part of this, we're doing what we
>>> can for the Keycloak Node.js pieces.
>>>
>>> As it stands now, I understand that versioning of adapters must remain
>>> in lockstep with Keycloak core. I understand the motivation for this, but
>>> want to push back on this just a little bit, and open it up for discussion.
>>>
>>> I see a couple of scenarios where this is potentially problematic. I am
>>> using Node.js and NPM here, but I think the concerns should apply to any
>>> adapter that is part of an ecosystem outside of Java.
>>>
>>> 1) There is a security flaw in some 3rd party dependency of the adapter,
>>> discovered the day of a Keycloak core release. This renders the "latest"
>>> version of an adapter useless until a new Keycloak server is released. I
>>> understand that the release cadence is anticipated to be approximately
>>> every 6 weeks (which is laudable), but still that's > 1 month that users
>>> have to wait for a security fix.
>>>
>>
>>
>> In my opinion it depends how critical and exploitable is the
>> vulnerability. For critical updates, I'd say that the adapter should be
>> release ASAP and the patch number increased and released. For example:
>> vulnerability found at 0.0.16 we just bump it up to 0.0.17 and release.
>>
>>
>>>
>>> 2) There is no change in the adapter between releases of Keycloak
>>> server. In this case, it's not necessarily a problem to release a new
>>> adapter version, but it seems noisy and pointless if the bits are exactly
>>> the same.
>>>
>>> When we look at version numbers, they are typically MAJOR.MINOR.PATCH
>>> with possibly a pre-release suffix like -Alpha1. I would like to discuss
>>> the possibility for adapters to issue patch level releases independent of a
>>> server release. This would allow for MAJOR.MINOR versions to remain
>>> consistent so to communicate compatibility with a given Keycloak server
>>> version. But would provide flexibility for adapters to deal with both
>>> issues noted above.
>>>
>>
>> I'm +1 on keeping independent version numbers from the server and state
>> something like connect-keycloak v0.0.17 is compatible with Keycloak server
>> 1.9.2.Final for example. But I'm -1 on independent release dates ? unless
>> we have a critical security fix.
>>
>> If we release whenever we want the adapters, would be hard to test,
>> because we don't have bandwith for it. I see as something which could
>> become out of control like v0.0.15, v0.0.16, v0.0.17 is compatible with KC
>> 1.9.2, but v0.0.18 only works with KC 2.0.x.
>>
>>>
>>> And just for the sake of argument, let's look at a hypothetical
>>> situation where Keycloak is baptized a Product, and the release cadence
>>> slows down significantly to every 12-18 months. What if a major security
>>> flaw is discovered in an adapter? Should this trigger a new release of
>>> Keycloak server itself? Would it not be better to allow the adapter to
>>> issue a patch level release instead?
>>>
>>
>> +1 for just the adapter issue a patch level release.
>>
>> tl;dr my personal opinion is (anything that I'm going to say here can be
>> innacurate, because I don't have the whole context about the conversations
>> during the F2F):
>>
>> - Adapters should be released on exactly the same dates as the server
>> (with one single exception, critical security fixes)
>>
>
> They are actually going to be released by the same process.
>
>
>> - The version number should be independent, in this way we state
>> something like Node.js adapters version 0.0.17 are fully compatible with KC
>> 1.9.x.
>>
>
> No, version is the same as the server. Having to install server 1.9.5, jee
> adapter 1.8.7, javascript adapter 1.0.5 and nodejs adapter 0.5.0 is just
> crazy.
>

I'm sorry but I have to disagree, we already do it for years with 3rd party
dependencies into our projects. For security fixes where you have the
adapter and the server with version as 1.9.2.Final, we cannot bump up the
version of the server because the adapter has a critical security issue and
have to be released.

But if this is a decision already taken, I'm not taking this road
discussing why I think it's bad.

>
>
>>
>>
>>>
>>> If you've read this far - thanks! Looking forward to your thoughts.
>>>
>>> Lance
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/cdd92b4d/attachment-0001.html 

From guus.der.kinderen at gmail.com  Wed Apr 13 07:41:50 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Wed, 13 Apr 2016 13:41:50 +0200
Subject: [keycloak-dev] Release testing
In-Reply-To: <CAJgngAeMhwt6oQ8bRLDMQXE1djAPy=PEbXD06zoOAoZ6Dw7Gmg@mail.gmail.com>
References: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
	<CAMJaV9mE8D+_drEjxkvrEYtvphTE+=BC4yQMiRDw3XBQZVEY_Q@mail.gmail.com>
	<CAJgngAeMhwt6oQ8bRLDMQXE1djAPy=PEbXD06zoOAoZ6Dw7Gmg@mail.gmail.com>
Message-ID: <CAMJaV9mt4RXXX2r6qRdcvgU+6Sw0PrV7VmSuFpF0tGLyNeAw2g@mail.gmail.com>

No roles specifcally. I just used that one-time registration form that pops
up when you attempt to log in to a completely fresh keycloak install.

I will pull the latest changes, and retry.

On 13 April 2016 at 13:32, Stian Thorgersen <sthorger at redhat.com> wrote:

> Tried to reproduce in 1.9.x now, but couldn't. What role mappings did you
> give the new user?
>
> On 13 April 2016 at 12:18, Guus der Kinderen <guus.der.kinderen at gmail.com>
> wrote:
>
>> That spreadsheet is not open to the public - so I don't know if this is
>> covered:
>> http://lists.jboss.org/pipermail/keycloak-dev/2016-April/006960.html
>>
>> That's still an issue for me.
>>
>>  - Guus
>>
>> On 13 April 2016 at 12:15, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>>> We're ready to start testing for 1.9.2 release. Please get started going
>>> through:
>>>
>>>
>>> https://docs.google.com/spreadsheets/d/1C1nCxbjehFSMhf2dDzXeH1Q2AYsozQ5mcZkhpac6NOU
>>>
>>> Everyone should know the drill by now, so I'm not going to list the
>>> steps this time around.
>>>
>>> _______________________________________________
>>> 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/20160413/94f17845/attachment.html 

From sthorger at redhat.com  Wed Apr 13 07:45:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 13:45:09 +0200
Subject: [keycloak-dev] Adapter Versioning
In-Reply-To: <CAM5SUC6NGRRkyx7FHqF+OkQ-B2ywnPv4nUXLEB3FF07Ps9_p0g@mail.gmail.com>
References: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
	<CAM5SUC4ky428vtvKXxvTfQLMdExDLEb8Y7zpZ12e2OCqF4dPYQ@mail.gmail.com>
	<CAJgngAdVUbkf_oZ9zQToyfqpuOqAvqXpEHHhVtBsZtY13_jiNw@mail.gmail.com>
	<CAM5SUC6NGRRkyx7FHqF+OkQ-B2ywnPv4nUXLEB3FF07Ps9_p0g@mail.gmail.com>
Message-ID: <CAJgngAeBvpK5qw_H6s1coSpfsAhiFGiqaH5NiFaMGXP1q3corw@mail.gmail.com>

On 13 April 2016 at 13:37, Bruno Oliveira <bruno at abstractj.org> wrote:

>
>
> On Wed, Apr 13, 2016 at 1:41 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> All existing adapters follow:
>> * Release at the same time as server (by the same Jenkins job)
>> * Same version as the server
>>
>> Then the improvements we discussed at F2F are:
>> * Add note to release notes to show what adapters are required to update
>> * Add a separate adapters guide, with a chapter for each adapter.
>>
>> That is the simplest and cleanest solution IMO. Further, just to point
>> out that I want all official Keycloak adapters to follow the same process.
>>
>> On 12 April 2016 at 21:54, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>>> On Tue, Apr 12, 2016 at 2:25 PM Lance Ball <lball at redhat.com> wrote:
>>>
>>>> Hi all
>>>>
>>>> I've been emailing with Stian about versioning in the "Node.js adapter
>>>> releases" thread, but as he pointed out, some of my concerns are broader
>>>> than just Node.js and so I am broadening the conversation a bit.
>>>>
>>>> Background: I am working as part of a Node.js RHT "middleware" team to,
>>>> among other things, contribute towards the development of Node.js modules
>>>> for our existing JBoss technologies. As part of this, we're doing what we
>>>> can for the Keycloak Node.js pieces.
>>>>
>>>> As it stands now, I understand that versioning of adapters must remain
>>>> in lockstep with Keycloak core. I understand the motivation for this, but
>>>> want to push back on this just a little bit, and open it up for discussion.
>>>>
>>>> I see a couple of scenarios where this is potentially problematic. I am
>>>> using Node.js and NPM here, but I think the concerns should apply to any
>>>> adapter that is part of an ecosystem outside of Java.
>>>>
>>>> 1) There is a security flaw in some 3rd party dependency of the
>>>> adapter, discovered the day of a Keycloak core release. This renders the
>>>> "latest" version of an adapter useless until a new Keycloak server is
>>>> released. I understand that the release cadence is anticipated to be
>>>> approximately every 6 weeks (which is laudable), but still that's > 1 month
>>>> that users have to wait for a security fix.
>>>>
>>>
>>>
>>> In my opinion it depends how critical and exploitable is the
>>> vulnerability. For critical updates, I'd say that the adapter should be
>>> release ASAP and the patch number increased and released. For example:
>>> vulnerability found at 0.0.16 we just bump it up to 0.0.17 and release.
>>>
>>>
>>>>
>>>> 2) There is no change in the adapter between releases of Keycloak
>>>> server. In this case, it's not necessarily a problem to release a new
>>>> adapter version, but it seems noisy and pointless if the bits are exactly
>>>> the same.
>>>>
>>>> When we look at version numbers, they are typically MAJOR.MINOR.PATCH
>>>> with possibly a pre-release suffix like -Alpha1. I would like to discuss
>>>> the possibility for adapters to issue patch level releases independent of a
>>>> server release. This would allow for MAJOR.MINOR versions to remain
>>>> consistent so to communicate compatibility with a given Keycloak server
>>>> version. But would provide flexibility for adapters to deal with both
>>>> issues noted above.
>>>>
>>>
>>> I'm +1 on keeping independent version numbers from the server and state
>>> something like connect-keycloak v0.0.17 is compatible with Keycloak server
>>> 1.9.2.Final for example. But I'm -1 on independent release dates ? unless
>>> we have a critical security fix.
>>>
>>> If we release whenever we want the adapters, would be hard to test,
>>> because we don't have bandwith for it. I see as something which could
>>> become out of control like v0.0.15, v0.0.16, v0.0.17 is compatible with KC
>>> 1.9.2, but v0.0.18 only works with KC 2.0.x.
>>>
>>>>
>>>> And just for the sake of argument, let's look at a hypothetical
>>>> situation where Keycloak is baptized a Product, and the release cadence
>>>> slows down significantly to every 12-18 months. What if a major security
>>>> flaw is discovered in an adapter? Should this trigger a new release of
>>>> Keycloak server itself? Would it not be better to allow the adapter to
>>>> issue a patch level release instead?
>>>>
>>>
>>> +1 for just the adapter issue a patch level release.
>>>
>>> tl;dr my personal opinion is (anything that I'm going to say here can be
>>> innacurate, because I don't have the whole context about the conversations
>>> during the F2F):
>>>
>>> - Adapters should be released on exactly the same dates as the server
>>> (with one single exception, critical security fixes)
>>>
>>
>> They are actually going to be released by the same process.
>>
>>
>>> - The version number should be independent, in this way we state
>>> something like Node.js adapters version 0.0.17 are fully compatible with KC
>>> 1.9.x.
>>>
>>
>> No, version is the same as the server. Having to install server 1.9.5,
>> jee adapter 1.8.7, javascript adapter 1.0.5 and nodejs adapter 0.5.0 is
>> just crazy.
>>
>
> I'm sorry but I have to disagree, we already do it for years with 3rd
> party dependencies into our projects. For security fixes where you have the
> adapter and the server with version as 1.9.2.Final, we cannot bump up the
> version of the server because the adapter has a critical security issue and
> have to be released.
>
> But if this is a decision already taken, I'm not taking this road
> discussing why I think it's bad.
>

The decision has been made, but nothing is set in stone. I suggest we try
the approach we decided at the f2f and adjust later if it becomes a problem.


>
>>
>>>
>>>
>>>>
>>>> If you've read this far - thanks! Looking forward to your thoughts.
>>>>
>>>> Lance
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/97c7a44d/attachment.html 

From ssilvert at redhat.com  Wed Apr 13 09:28:18 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 13 Apr 2016 09:28:18 -0400
Subject: [keycloak-dev] Release testing
In-Reply-To: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
References: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
Message-ID: <570E4972.4090504@redhat.com>

Is there somewhere to download the release or do you want us to just 
check out the 1.9.x branch?

On 4/13/2016 6:15 AM, Stian Thorgersen wrote:
> We're ready to start testing for 1.9.2 release. Please get started 
> going through:
>
> https://docs.google.com/spreadsheets/d/1C1nCxbjehFSMhf2dDzXeH1Q2AYsozQ5mcZkhpac6NOU
>
> Everyone should know the drill by now, so I'm not going to list the 
> steps this time around.
>
>
> _______________________________________________
> 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/20160413/43ba1981/attachment-0001.html 

From sthorger at redhat.com  Wed Apr 13 09:39:54 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 15:39:54 +0200
Subject: [keycloak-dev] Release testing
In-Reply-To: <570E4972.4090504@redhat.com>
References: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
	<570E4972.4090504@redhat.com>
Message-ID: <CAJgngAcy++j=nvKihurxPF3xsT8DCyqUAqiz0cGLomSo_E6bDg@mail.gmail.com>

Check out and build 1.9.x branch

On 13 April 2016 at 15:28, Stan Silvert <ssilvert at redhat.com> wrote:

> Is there somewhere to download the release or do you want us to just check
> out the 1.9.x branch?
>
>
> On 4/13/2016 6:15 AM, Stian Thorgersen wrote:
>
> We're ready to start testing for 1.9.2 release. Please get started going
> through:
>
>
> https://docs.google.com/spreadsheets/d/1C1nCxbjehFSMhf2dDzXeH1Q2AYsozQ5mcZkhpac6NOU
>
> Everyone should know the drill by now, so I'm not going to list the steps
> this time around.
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/d7668161/attachment.html 

From mposolda at redhat.com  Wed Apr 13 10:26:43 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Apr 2016 16:26:43 +0200
Subject: [keycloak-dev] Bug in UI?
In-Reply-To: <CAMJaV9krMEeLt-0P=CjB+XA86fQKrbcvr4sjvkymupVa9SVzbw@mail.gmail.com>
References: <CAMJaV9mo13KS+HVFyJzcmxcC0noPs-yDwkvxDJZaSjUT7o+6XA@mail.gmail.com>
	<CAM5SUC6MHX2Anrof0s6VyD8cED6tBXnq8Jhx5n6aONpDGRW9tA@mail.gmail.com>
	<CAMJaV9krMEeLt-0P=CjB+XA86fQKrbcvr4sjvkymupVa9SVzbw@mail.gmail.com>
Message-ID: <570E5723.7060202@redhat.com>

Maybe if you clear browser cache it will help?

We have version in URI of static resources (CSS, HTML, freemarker 
templates etc), so if you work just with released versions like 
"1.8.0.Final" or "1.9.1.Final", the browser cache is not an issue as 
it's different URI for each version. But you're doing some development 
and building KC from sources, so if there are changes, the version is 
still "1.9.2-SNAPSHOT", hence you can see stale content of some file 
through your browser cache.

Marek

On 12/04/16 17:12, Guus der Kinderen wrote:
> Thanks for the feedback. I didn't try master yet, because I will be 
> deploying the upcoming 1.9.2 (master is currently at 2.0.0).
>
>  - Guus
>
> On 12 April 2016 at 17:03, Bruno Oliveira <bruno at abstractj.org 
> <mailto:bruno at abstractj.org>> wrote:
>
>     Hi Guus, everything is working here for me. Maybe you should try
>     it against the latest changes on master?
>
>     On Tue, Apr 12, 2016 at 7:10 AM Guus der Kinderen
>     <guus.der.kinderen at gmail.com <mailto:guus.der.kinderen at gmail.com>>
>     wrote:
>
>         Hi,
>
>         I did not try to reproduce this on master branch, but got it
>         twice now on 1.9.x. The branch HEAD is
>         commit b01f522acea6b6c5c6f487dc626a24ca928da77d
>
>         After I build the distribution...
>
>         $ mvn clean install -DskipTests -Pdistribution
>
>
>         ... extract the distribution ...
>
>         $ cd /distribution/server-dist/target/
>         $ tar zxvf keycloak-1.9.2.Final-SNAPSHOT.tar.gz
>
>
>         ... and start a standalone instance ...
>
>         $ cd /keycloak-1.9.2.Final-SNAPSHOT/bin
>         $ ./standalone.sh
>
>         ... open the webpage at http://localhost:8080/auth
>         ... create a new user
>         ... login to the administration console with that user
>         ... go to the list of clients
>         ... and open (or click 'edit') on any of the clients
>
>         Then the webpage that I'm looking at appears to be broken. I'm
>         looking at the template itself, I think.
>
>         Is this me, or can someone reproduce this?
>
>          - Guus
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/66064fc2/attachment.html 

From mposolda at redhat.com  Wed Apr 13 11:46:15 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Apr 2016 17:46:15 +0200
Subject: [keycloak-dev] Release testing
In-Reply-To: <CAJgngAcy++j=nvKihurxPF3xsT8DCyqUAqiz0cGLomSo_E6bDg@mail.gmail.com>
References: <CAJgngAdtqCPOmvaK+QyPfDVYH9UQevsuEfzgHxF5k4azmxYQ9A@mail.gmail.com>
	<570E4972.4090504@redhat.com>
	<CAJgngAcy++j=nvKihurxPF3xsT8DCyqUAqiz0cGLomSo_E6bDg@mail.gmail.com>
Message-ID: <570E69C7.1010808@redhat.com>

Fyi. Fuse adapter doesn't work. Created 
https://issues.jboss.org/browse/KEYCLOAK-2816 . Seems the solution would 
be to rename some package, but that will affect lots of classes inside 
adapters. If you have opportunity to test anything else then adapters, 
please rather go this way as it seems that everything related to 
adapters (including examples) might need to be retested :(

Marek

On 13/04/16 15:39, Stian Thorgersen wrote:
> Check out and build 1.9.x branch
>
> On 13 April 2016 at 15:28, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     Is there somewhere to download the release or do you want us to
>     just check out the 1.9.x branch?
>
>
>     On 4/13/2016 6:15 AM, Stian Thorgersen wrote:
>>     We're ready to start testing for 1.9.2 release. Please get
>>     started going through:
>>
>>     https://docs.google.com/spreadsheets/d/1C1nCxbjehFSMhf2dDzXeH1Q2AYsozQ5mcZkhpac6NOU
>>
>>     Everyone should know the drill by now, so I'm not going to list
>>     the steps this time around.
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/7c9bac63/attachment.html 

From mposolda at redhat.com  Wed Apr 13 12:10:09 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Apr 2016 18:10:09 +0200
Subject: [keycloak-dev] Renamed package because of fuse
Message-ID: <570E6F61.1050200@redhat.com>

Found that fuse adapter doesn't work due to adapters packaging changes. 
JIRA is here: https://issues.jboss.org/browse/KEYCLOAK-2816

Among some minor things, the biggest issue is that osgi doesn't work 
properly if there are 2 modules with classes inside same package. There 
is "adapter-spi" and "adapter-spi-public" modules with both having 
classes inside package "org.keycloak.adapters.spi". So the easiest 
solution was just to rename the package.

There was possibility to rename either:
(1) the one inside "adapter-spi"
(2) or the one inside "adapter-spi-public" .

I've actually chose the (1) and renamed the one inside "adapter-spi" to 
"org.keycloak.adapters.spi .internal". Only reason is that there might 
be some users, who are using classes AuthenticationError or LogoutError, 
so they don't need to change the code of their applications because 
upgrade. On the other hand the (2) (rename the package inside 
"adapter-spi-public" to "org.keycloak.adapters.spi.public" and keep the 
one inside "adapter-spi" unrenamed) have the advantage of better 
consistency among module names and package names. So if you rather want 
me to go this way, let me know and I can change it.

For now, the PR against 1.9.x for path1 is here: 
https://github.com/keycloak/keycloak/pull/2614 . There are 72 affected 
files because of package renamed, but all of them are inside adapters. 
Will send PR against master too if you agree with the path1. Not sure if 
we rather need to retest all the examples because of the change... :-(

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

From bburke at redhat.com  Wed Apr 13 12:18:44 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Apr 2016 12:18:44 -0400
Subject: [keycloak-dev] Renamed package because of fuse
In-Reply-To: <570E6F61.1050200@redhat.com>
References: <570E6F61.1050200@redhat.com>
Message-ID: <570E7164.3070903@redhat.com>

Wait!  Maybe we should just merge adapter-spi and adapter-spi-public.  
Its not that big a deal to have adapter-spi be public.

On 4/13/2016 12:10 PM, Marek Posolda wrote:
> Found that fuse adapter doesn't work due to adapters packaging 
> changes. JIRA is here: https://issues.jboss.org/browse/KEYCLOAK-2816
>
> Among some minor things, the biggest issue is that osgi doesn't work 
> properly if there are 2 modules with classes inside same package. 
> There is "adapter-spi" and "adapter-spi-public" modules with both 
> having classes inside package "org.keycloak.adapters.spi". So the 
> easiest solution was just to rename the package.
>
> There was possibility to rename either:
> (1) the one inside "adapter-spi"
> (2) or the one inside "adapter-spi-public" .
>
> I've actually chose the (1) and renamed the one inside "adapter-spi" 
> to "org.keycloak.adapters.spi .internal". Only reason is that there 
> might be some users, who are using classes AuthenticationError or 
> LogoutError, so they don't need to change the code of their 
> applications because upgrade. On the other hand the (2) (rename the 
> package inside "adapter-spi-public" to 
> "org.keycloak.adapters.spi.public" and keep the one inside 
> "adapter-spi" unrenamed) have the advantage of better consistency 
> among module names and package names. So if you rather want me to go 
> this way, let me know and I can change it.
>
> For now, the PR against 1.9.x for path1 is here: 
> https://github.com/keycloak/keycloak/pull/2614 . There are 72 affected 
> files because of package renamed, but all of them are inside adapters. 
> Will send PR against master too if you agree with the path1. Not sure 
> if we rather need to retest all the examples because of the change... :-(
>
> Marek
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From psilva at redhat.com  Wed Apr 13 13:48:06 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 13 Apr 2016 13:48:06 -0400 (EDT)
Subject: [keycloak-dev] Authorization Services PR
In-Reply-To: <1938519291.50685564.1460569574183.JavaMail.zimbra@redhat.com>
Message-ID: <122507168.50689545.1460569686701.JavaMail.zimbra@redhat.com>

Hi,

    I've sent the first PR [1] with the necessary changes to get the AuthZ Services in.

    I'm still working with tests.

    New section was added to documentation about Fine-grained Authorization. Any feedback is welcome !

Regards.
Pedro Igor

[1] https://github.com/keycloak/keycloak/pull/2617

From sthorger at redhat.com  Wed Apr 13 14:03:26 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 20:03:26 +0200
Subject: [keycloak-dev] Renamed package because of fuse
In-Reply-To: <570E7164.3070903@redhat.com>
References: <570E6F61.1050200@redhat.com>
	<570E7164.3070903@redhat.com>
Message-ID: <CAJgngAeM1KgZMPGNF1dakS7O4ngBN7FXsAAMr0oLJA8N9PSuCg@mail.gmail.com>

Rename or merge either works for me. We need it resolved asap though. Yes,
we're going to have to re-test all adapters and examples because of this :(

On 13 April 2016 at 18:18, Bill Burke <bburke at redhat.com> wrote:

> Wait!  Maybe we should just merge adapter-spi and adapter-spi-public.  Its
> not that big a deal to have adapter-spi be public.
>
>
> On 4/13/2016 12:10 PM, Marek Posolda wrote:
>
> Found that fuse adapter doesn't work due to adapters packaging changes.
> JIRA is here: https://issues.jboss.org/browse/KEYCLOAK-2816
>
> Among some minor things, the biggest issue is that osgi doesn't work
> properly if there are 2 modules with classes inside same package. There is
> "adapter-spi" and "adapter-spi-public" modules with both having classes
> inside package "org.keycloak.adapters.spi". So the easiest solution was
> just to rename the package.
>
> There was possibility to rename either:
> (1) the one inside "adapter-spi"
> (2) or the one inside "adapter-spi-public" .
>
> I've actually chose the (1) and renamed the one inside "adapter-spi" to
> "org.keycloak.adapters.spi .internal". Only reason is that there might be
> some users, who are using classes AuthenticationError or LogoutError, so
> they don't need to change the code of their applications because upgrade.
> On the other hand the (2) (rename the package inside "adapter-spi-public"
> to "org.keycloak.adapters.spi.public" and keep the one inside "adapter-spi"
> unrenamed) have the advantage of better consistency among module names and
> package names. So if you rather want me to go this way, let me know and I
> can change it.
>
> For now, the PR against 1.9.x for path1 is here:
> <https://github.com/keycloak/keycloak/pull/2614>
> https://github.com/keycloak/keycloak/pull/2614 . There are 72 affected
> files because of package renamed, but all of them are inside adapters. Will
> send PR against master too if you agree with the path1. Not sure if we
> rather need to retest all the examples because of the change... :-(
>
> Marek
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160413/05e20a80/attachment.html 

From sthorger at redhat.com  Wed Apr 13 14:05:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Apr 2016 20:05:12 +0200
Subject: [keycloak-dev] Authorization Services PR
In-Reply-To: <122507168.50689545.1460569686701.JavaMail.zimbra@redhat.com>
References: <1938519291.50685564.1460569574183.JavaMail.zimbra@redhat.com>
	<122507168.50689545.1460569686701.JavaMail.zimbra@redhat.com>
Message-ID: <CAJgngAd8MG67CraevWd3tA9V-oVPVkJuwusb6xJZe_RBvf_e_g@mail.gmail.com>

That's a big PR! I won't have time to look at it this week, but promise to
do it next week.

On 13 April 2016 at 19:48, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
>     I've sent the first PR [1] with the necessary changes to get the AuthZ
> Services in.
>
>     I'm still working with tests.
>
>     New section was added to documentation about Fine-grained
> Authorization. Any feedback is welcome !
>
> Regards.
> Pedro Igor
>
> [1] https://github.com/keycloak/keycloak/pull/2617
> _______________________________________________
> 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/20160413/2922b08a/attachment.html 

From psilva at redhat.com  Wed Apr 13 14:09:46 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 13 Apr 2016 14:09:46 -0400 (EDT)
Subject: [keycloak-dev] Authorization Services PR
In-Reply-To: <CAJgngAd8MG67CraevWd3tA9V-oVPVkJuwusb6xJZe_RBvf_e_g@mail.gmail.com>
References: <1938519291.50685564.1460569574183.JavaMail.zimbra@redhat.com>
	<122507168.50689545.1460569686701.JavaMail.zimbra@redhat.com>
	<CAJgngAd8MG67CraevWd3tA9V-oVPVkJuwusb6xJZe_RBvf_e_g@mail.gmail.com>
Message-ID: <312383484.50719680.1460570986509.JavaMail.zimbra@redhat.com>

Did you see the docs ? :) 

No problem. Until there I'll push the missing tests ...

----- Original Message -----
From: "Stian Thorgersen" <sthorger at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Wednesday, April 13, 2016 3:05:12 PM
Subject: Re: [keycloak-dev] Authorization Services PR

That's a big PR! I won't have time to look at it this week, but promise to
do it next week.

On 13 April 2016 at 19:48, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
>     I've sent the first PR [1] with the necessary changes to get the AuthZ
> Services in.
>
>     I'm still working with tests.
>
>     New section was added to documentation about Fine-grained
> Authorization. Any feedback is welcome !
>
> Regards.
> Pedro Igor
>
> [1] https://github.com/keycloak/keycloak/pull/2617
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Wed Apr 13 14:10:18 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Apr 2016 20:10:18 +0200
Subject: [keycloak-dev] Renamed package because of fuse
In-Reply-To: <CAJgngAeM1KgZMPGNF1dakS7O4ngBN7FXsAAMr0oLJA8N9PSuCg@mail.gmail.com>
References: <570E6F61.1050200@redhat.com> <570E7164.3070903@redhat.com>
	<CAJgngAeM1KgZMPGNF1dakS7O4ngBN7FXsAAMr0oLJA8N9PSuCg@mail.gmail.com>
Message-ID: <570E8B8A.7020606@redhat.com>

Ok, I've closed the https://github.com/keycloak/keycloak/pull/2614

Do you want me to look at merging modules or are you looking at it Bill? 
I can sort it, but will be able to start on it no earlier than tomorrow 
morning Europe time :/

Marek

On 13/04/16 20:03, Stian Thorgersen wrote:
> Rename or merge either works for me. We need it resolved asap though. 
> Yes, we're going to have to re-test all adapters and examples because 
> of this :(
>
> On 13 April 2016 at 18:18, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Wait!  Maybe we should just merge adapter-spi and
>     adapter-spi-public.  Its not that big a deal to have adapter-spi
>     be public.
>
>
>     On 4/13/2016 12:10 PM, Marek Posolda wrote:
>>     Found that fuse adapter doesn't work due to adapters packaging
>>     changes. JIRA is here: https://issues.jboss.org/browse/KEYCLOAK-2816
>>
>>     Among some minor things, the biggest issue is that osgi doesn't
>>     work properly if there are 2 modules with classes inside same
>>     package. There is "adapter-spi" and "adapter-spi-public" modules
>>     with both having classes inside package
>>     "org.keycloak.adapters.spi". So the easiest solution was just to
>>     rename the package.
>>
>>     There was possibility to rename either:
>>     (1) the one inside "adapter-spi"
>>     (2) or the one inside "adapter-spi-public" .
>>
>>     I've actually chose the (1) and renamed the one inside
>>     "adapter-spi" to "org.keycloak.adapters.spi .internal". Only
>>     reason is that there might be some users, who are using classes
>>     AuthenticationError or LogoutError, so they don't need to change
>>     the code of their applications because upgrade. On the other hand
>>     the (2) (rename the package inside "adapter-spi-public" to
>>     "org.keycloak.adapters.spi.public" and keep the one inside
>>     "adapter-spi" unrenamed) have the advantage of better consistency
>>     among module names and package names. So if you rather want me to
>>     go this way, let me know and I can change it.
>>
>>     For now, the PR against 1.9.x for path1 is here:
>>     https://github.com/keycloak/keycloak/pull/2614 . There are 72
>>     affected files because of package renamed, but all of them are
>>     inside adapters. Will send PR against master too if you agree
>>     with the path1. Not sure if we rather need to retest all the
>>     examples because of the change... :-(
>>
>>     Marek
>>
>>
>>     _______________________________________________
>>     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
>
>     -- 
>     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
>
>
>
>
> _______________________________________________
> 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/20160413/80b51f6c/attachment-0001.html 

From psilva at redhat.com  Wed Apr 13 14:11:13 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 13 Apr 2016 14:11:13 -0400 (EDT)
Subject: [keycloak-dev] Authorization Services PR
In-Reply-To: <CAJgngAd8MG67CraevWd3tA9V-oVPVkJuwusb6xJZe_RBvf_e_g@mail.gmail.com>
References: <1938519291.50685564.1460569574183.JavaMail.zimbra@redhat.com>
	<122507168.50689545.1460569686701.JavaMail.zimbra@redhat.com>
	<CAJgngAd8MG67CraevWd3tA9V-oVPVkJuwusb6xJZe_RBvf_e_g@mail.gmail.com>
Message-ID: <819429856.50721294.1460571073830.JavaMail.zimbra@redhat.com>

Btw, I've tried to avoid deep changes to other modules. You'll see that changes to existing KC resources are pretty minimal.

Beside adding new "authorization" packages on server-spi and services. The rest of the changes are related with distribution.

----- Original Message -----
From: "Stian Thorgersen" <sthorger at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Wednesday, April 13, 2016 3:05:12 PM
Subject: Re: [keycloak-dev] Authorization Services PR

That's a big PR! I won't have time to look at it this week, but promise to
do it next week.

On 13 April 2016 at 19:48, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
>     I've sent the first PR [1] with the necessary changes to get the AuthZ
> Services in.
>
>     I'm still working with tests.
>
>     New section was added to documentation about Fine-grained
> Authorization. Any feedback is welcome !
>
> Regards.
> Pedro Igor
>
> [1] https://github.com/keycloak/keycloak/pull/2617
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Wed Apr 13 14:28:56 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Apr 2016 14:28:56 -0400
Subject: [keycloak-dev] Renamed package because of fuse
In-Reply-To: <CAJgngAeM1KgZMPGNF1dakS7O4ngBN7FXsAAMr0oLJA8N9PSuCg@mail.gmail.com>
References: <570E6F61.1050200@redhat.com> <570E7164.3070903@redhat.com>
	<CAJgngAeM1KgZMPGNF1dakS7O4ngBN7FXsAAMr0oLJA8N9PSuCg@mail.gmail.com>
Message-ID: <570E8FE8.3060205@redhat.com>

Has to be a merge, otherwise you break backward compatibility.

On 4/13/2016 2:03 PM, Stian Thorgersen wrote:
> Rename or merge either works for me. We need it resolved asap though. 
> Yes, we're going to have to re-test all adapters and examples because 
> of this :(
>
> On 13 April 2016 at 18:18, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Wait!  Maybe we should just merge adapter-spi and
>     adapter-spi-public.  Its not that big a deal to have adapter-spi
>     be public.
>
>
>     On 4/13/2016 12:10 PM, Marek Posolda wrote:
>>     Found that fuse adapter doesn't work due to adapters packaging
>>     changes. JIRA is here: https://issues.jboss.org/browse/KEYCLOAK-2816
>>
>>     Among some minor things, the biggest issue is that osgi doesn't
>>     work properly if there are 2 modules with classes inside same
>>     package. There is "adapter-spi" and "adapter-spi-public" modules
>>     with both having classes inside package
>>     "org.keycloak.adapters.spi". So the easiest solution was just to
>>     rename the package.
>>
>>     There was possibility to rename either:
>>     (1) the one inside "adapter-spi"
>>     (2) or the one inside "adapter-spi-public" .
>>
>>     I've actually chose the (1) and renamed the one inside
>>     "adapter-spi" to "org.keycloak.adapters.spi .internal". Only
>>     reason is that there might be some users, who are using classes
>>     AuthenticationError or LogoutError, so they don't need to change
>>     the code of their applications because upgrade. On the other hand
>>     the (2) (rename the package inside "adapter-spi-public" to
>>     "org.keycloak.adapters.spi.public" and keep the one inside
>>     "adapter-spi" unrenamed) have the advantage of better consistency
>>     among module names and package names. So if you rather want me to
>>     go this way, let me know and I can change it.
>>
>>     For now, the PR against 1.9.x for path1 is here:
>>     https://github.com/keycloak/keycloak/pull/2614 . There are 72
>>     affected files because of package renamed, but all of them are
>>     inside adapters. Will send PR against master too if you agree
>>     with the path1. Not sure if we rather need to retest all the
>>     examples because of the change... :-(
>>
>>     Marek
>>
>>
>>     _______________________________________________
>>     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
>
>     -- 
>     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
>
>

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

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

From bburke at redhat.com  Wed Apr 13 14:29:24 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Apr 2016 14:29:24 -0400
Subject: [keycloak-dev] Renamed package because of fuse
In-Reply-To: <570E8B8A.7020606@redhat.com>
References: <570E6F61.1050200@redhat.com> <570E7164.3070903@redhat.com>
	<CAJgngAeM1KgZMPGNF1dakS7O4ngBN7FXsAAMr0oLJA8N9PSuCg@mail.gmail.com>
	<570E8B8A.7020606@redhat.com>
Message-ID: <570E9004.3040400@redhat.com>

I'll look into it tonight after I get home from driving kid around.

On 4/13/2016 2:10 PM, Marek Posolda wrote:
> Ok, I've closed the https://github.com/keycloak/keycloak/pull/2614
>
> Do you want me to look at merging modules or are you looking at it 
> Bill? I can sort it, but will be able to start on it no earlier than 
> tomorrow morning Europe time :/
>
> Marek
>
> On 13/04/16 20:03, Stian Thorgersen wrote:
>> Rename or merge either works for me. We need it resolved asap though. 
>> Yes, we're going to have to re-test all adapters and examples because 
>> of this :(
>>
>> On 13 April 2016 at 18:18, Bill Burke <bburke at redhat.com 
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     Wait!  Maybe we should just merge adapter-spi and
>>     adapter-spi-public. Its not that big a deal to have adapter-spi
>>     be public.
>>
>>
>>     On 4/13/2016 12:10 PM, Marek Posolda wrote:
>>>     Found that fuse adapter doesn't work due to adapters packaging
>>>     changes. JIRA is here: https://issues.jboss.org/browse/KEYCLOAK-2816
>>>
>>>     Among some minor things, the biggest issue is that osgi doesn't
>>>     work properly if there are 2 modules with classes inside same
>>>     package. There is "adapter-spi" and "adapter-spi-public" modules
>>>     with both having classes inside package
>>>     "org.keycloak.adapters.spi". So the easiest solution was just to
>>>     rename the package.
>>>
>>>     There was possibility to rename either:
>>>     (1) the one inside "adapter-spi"
>>>     (2) or the one inside "adapter-spi-public" .
>>>
>>>     I've actually chose the (1) and renamed the one inside
>>>     "adapter-spi" to "org.keycloak.adapters.spi .internal". Only
>>>     reason is that there might be some users, who are using classes
>>>     AuthenticationError or LogoutError, so they don't need to change
>>>     the code of their applications because upgrade. On the other
>>>     hand the (2) (rename the package inside "adapter-spi-public" to
>>>     "org.keycloak.adapters.spi.public" and keep the one inside
>>>     "adapter-spi" unrenamed) have the advantage of better
>>>     consistency among module names and package names. So if you
>>>     rather want me to go this way, let me know and I can change it.
>>>
>>>     For now, the PR against 1.9.x for path1 is here:
>>>     https://github.com/keycloak/keycloak/pull/2614 . There are 72
>>>     affected files because of package renamed, but all of them are
>>>     inside adapters. Will send PR against master too if you agree
>>>     with the path1. Not sure if we rather need to retest all the
>>>     examples because of the change... :-(
>>>
>>>     Marek
>>>
>>>
>>>     _______________________________________________
>>>     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
>>
>>     -- 
>>     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
>>
>>
>>
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/45c8da83/attachment.html 

From sthorger at redhat.com  Thu Apr 14 00:53:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Apr 2016 06:53:49 +0200
Subject: [keycloak-dev] Adapter Versioning
In-Reply-To: <CABRDmicvhtVtV3UzwqYVP6gb=8YhgRaGHVAWOTXvxKN9bCJ=PA@mail.gmail.com>
References: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
	<CAJgngAecnFvfq-bRvGQ1ikvpNcJnddHphAqsLYxFyPNqKacO+w@mail.gmail.com>
	<CABRDmicvhtVtV3UzwqYVP6gb=8YhgRaGHVAWOTXvxKN9bCJ=PA@mail.gmail.com>
Message-ID: <CAJgngAf_snX0MS6sNQ2rSGU7phcbZFXF8yNB2-OSrCyWCKe_Tw@mail.gmail.com>

Adding list back

On 13 April 2016 at 21:27, Lance Ball <lball at redhat.com> wrote:

> Some comments inline...
>
> On Wed, Apr 13, 2016 at 12:36 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On 12 April 2016 at 19:25, Lance Ball <lball at redhat.com> wrote:
>>
>>>
>>> 1) There is a security flaw in some 3rd party dependency of the adapter,
>>> discovered the day of a Keycloak core release. This renders the "latest"
>>> version of an adapter useless until a new Keycloak server is released. I
>>> understand that the release cadence is anticipated to be approximately
>>> every 6 weeks (which is laudable), but still that's > 1 month that users
>>> have to wait for a security fix.
>>>
>>
>> Non-issue as we will push out a release for a critical security fix as
>> soon as possible. Having a single release makes it actually easier to do.
>>
>
> I'll take your word for it, but I honestly don't see how pushing a new
> release of _everything_ can possibly be easier than, for example `npm
> publish` for a single artifact.
>

Releasing everything is going to be a "single" button click. Having the
ability to release micro releases of adapters may be something to consider
in the future if it does indeed become a problem.


>
>
>>
>>
>>> 2) There is no change in the adapter between releases of Keycloak
>>> server. In this case, it's not necessarily a problem to release a new
>>> adapter version, but it seems noisy and pointless if the bits are exactly
>>> the same.
>>>
>>
>> The plan is to have release notes that cover which adapters have changed
>> and which are required to upgrade (either because backwards compatibility
>> is broken with the server or due to a security fix)
>>
>
> But how is "Keycloak 2.7.0 works with foo-adapter 1.9.1 and greater" any
> better than "foo-adapter 1.9.1 works with Keycloak 1.9.1 and greater"? The
> first scenario is what will happen if adapters march in lockstep with
> Keycloak server, and the second is what will happen if they are released
> only when necessary. In either case, it is possible to be running different
> version numbers for foo-adapter and Keycloak server and still be functional.
>

Being able to grab same version of everything is nice. Being able to not
have to upgrade everything is nice.

Having to figure out what version belongs to what as a first time adapter
or when adding a new adapter is not so nice.

Having to figure out what the version is going to be for each individual
bit when we are doing a collective release is not so nice. Having different
release cycles, etc, etc.. is not so nice. We are a small team with a large
amount of work so we can afford to do this as it's additional time spent
doing releases, which we will be doing every 6 weeks!! so we want to reduce
the pain of doing a release as much as possible.


>
>
>>
>>
>>> When we look at version numbers, they are typically MAJOR.MINOR.PATCH
>>> with possibly a pre-release suffix like -Alpha1. I would like to discuss
>>> the possibility for adapters to issue patch level releases independent of a
>>> server release. This would allow for MAJOR.MINOR versions to remain
>>> consistent so to communicate compatibility with a given Keycloak server
>>> version. But would provide flexibility for adapters to deal with both
>>> issues noted above.
>>>
>>
>>> And just for the sake of argument, let's look at a hypothetical
>>> situation where Keycloak is baptized a Product, and the release cadence
>>> slows down significantly to every 12-18 months. What if a major security
>>> flaw is discovered in an adapter? Should this trigger a new release of
>>> Keycloak server itself? Would it not be better to allow the adapter to
>>> issue a patch level release instead?
>>>
>>
>> It won't and Keycloak is already becoming a product. Release cadence is 6
>> weeks in community.
>>
>
> To be clear, by "hypothetical situation", I didn't mean that Keycloak
> becoming a product was hypothetical. :) I'm saying that product releases
> are much slower, typically, than community releases. Will adapters be
> prevented from publishing an independent security fix in this scenario,
> where the product release cadence has slowed down? If not, we're going to
> hit version mismatches then anyway.
>

Product is different as here you actually have patches that are sent out to
customers. It would not be released as a release until the next micro of
the product as a whole. At least that's my understanding.


>
> Lance
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160414/4fe169e6/attachment-0001.html 

From mposolda at redhat.com  Thu Apr 14 03:08:05 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 14 Apr 2016 09:08:05 +0200
Subject: [keycloak-dev] Renamed package because of fuse
In-Reply-To: <570E9004.3040400@redhat.com>
References: <570E6F61.1050200@redhat.com> <570E7164.3070903@redhat.com>
	<CAJgngAeM1KgZMPGNF1dakS7O4ngBN7FXsAAMr0oLJA8N9PSuCg@mail.gmail.com>
	<570E8B8A.7020606@redhat.com> <570E9004.3040400@redhat.com>
Message-ID: <570F41D5.8040102@redhat.com>

I confirm Fuse works fine with the merge fix. Thanks!

Marek

On 13/04/16 20:29, Bill Burke wrote:
> I'll look into it tonight after I get home from driving kid around.
>
> On 4/13/2016 2:10 PM, Marek Posolda wrote:
>> Ok, I've closed the https://github.com/keycloak/keycloak/pull/2614
>>
>> Do you want me to look at merging modules or are you looking at it 
>> Bill? I can sort it, but will be able to start on it no earlier than 
>> tomorrow morning Europe time :/
>>
>> Marek
>>
>> On 13/04/16 20:03, Stian Thorgersen wrote:
>>> Rename or merge either works for me. We need it resolved asap 
>>> though. Yes, we're going to have to re-test all adapters and 
>>> examples because of this :(
>>>
>>> On 13 April 2016 at 18:18, Bill Burke <bburke at redhat.com 
>>> <mailto:bburke at redhat.com>> wrote:
>>>
>>>     Wait!  Maybe we should just merge adapter-spi and
>>>     adapter-spi-public. Its not that big a deal to have adapter-spi
>>>     be public.
>>>
>>>
>>>     On 4/13/2016 12:10 PM, Marek Posolda wrote:
>>>>     Found that fuse adapter doesn't work due to adapters packaging
>>>>     changes. JIRA is here:
>>>>     https://issues.jboss.org/browse/KEYCLOAK-2816
>>>>
>>>>     Among some minor things, the biggest issue is that osgi doesn't
>>>>     work properly if there are 2 modules with classes inside same
>>>>     package. There is "adapter-spi" and "adapter-spi-public"
>>>>     modules with both having classes inside package
>>>>     "org.keycloak.adapters.spi". So the easiest solution was just
>>>>     to rename the package.
>>>>
>>>>     There was possibility to rename either:
>>>>     (1) the one inside "adapter-spi"
>>>>     (2) or the one inside "adapter-spi-public" .
>>>>
>>>>     I've actually chose the (1) and renamed the one inside
>>>>     "adapter-spi" to "org.keycloak.adapters.spi .internal". Only
>>>>     reason is that there might be some users, who are using classes
>>>>     AuthenticationError or LogoutError, so they don't need to
>>>>     change the code of their applications because upgrade. On the
>>>>     other hand the (2) (rename the package inside
>>>>     "adapter-spi-public" to "org.keycloak.adapters.spi.public" and
>>>>     keep the one inside "adapter-spi" unrenamed) have the advantage
>>>>     of better consistency among module names and package names. So
>>>>     if you rather want me to go this way, let me know and I can
>>>>     change it.
>>>>
>>>>     For now, the PR against 1.9.x for path1 is here:
>>>>     https://github.com/keycloak/keycloak/pull/2614 . There are 72
>>>>     affected files because of package renamed, but all of them are
>>>>     inside adapters. Will send PR against master too if you agree
>>>>     with the path1. Not sure if we rather need to retest all the
>>>>     examples because of the change... :-(
>>>>
>>>>     Marek
>>>>
>>>>
>>>>     _______________________________________________
>>>>     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
>>>
>>>     -- 
>>>     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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

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

From sthorger at redhat.com  Thu Apr 14 03:28:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Apr 2016 09:28:35 +0200
Subject: [keycloak-dev] [keycloak-user] Documentation subjects - need
	feedback
In-Reply-To: <570D128D.2010906@redhat.com>
References: <570D0C44.6010907@redhat.com>
	<CAMu7ToqyCuOWBktKjx5QWD_vyK8w5WgpXEh0WVQxzNF5UKUncw@mail.gmail.com>
	<570D128D.2010906@redhat.com>
Message-ID: <CAJgngAfRTccBOzTfd_AmBCiP5pzHrN5xCNYP5gwF0F_Kv8PtSQ@mail.gmail.com>

A few things here:
https://issues.jboss.org/issues/?jql=statusCategory%20%3D%20new%20AND%20project%20%3D%2012313920%20AND%20fixVersion%20%3D%2012329877%20AND%20component%20%3D%20Documentation

On 12 April 2016 at 17:21, Bill Burke <bburke at redhat.com> wrote:

> Not sure what you mean by entitlements.  User role mappings is about all
> we got.  Please edit the Wiki directly.
>
>
> On 4/12/2016 11:06 AM, Lars Noldan wrote:
>
> I'd love more documentation about how entitlements are being handled by
> keycloak users, and best practices for configuring the same.
>
> On Tue, Apr 12, 2016 at 9:55 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> Created a wiki:
>>
>> https://github.com/keycloak/keycloak/wiki/Docs
>>
>> Please add things you want covered that are weak or non-existent in
>> documentation.  I'll be going through the email list as I know there
>> were a number of threads on this stuff too.  I'll post an outline
>> sometime next week after we have a few internal meetings on the subject.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160414/53f2f789/attachment.html 

From sthorger at redhat.com  Thu Apr 14 03:38:40 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Apr 2016 09:38:40 +0200
Subject: [keycloak-dev] 1.9.x branch updates (READ THIS!)
Message-ID: <CAJgngAfZGuPeKdDTCgREqvhmTAgGmpio4xPsHRgU2Fz9nPGfzA@mail.gmail.com>

We are not going to accept any more features, improvements or refactoring
to 1.9.x branch from now on!

Bug fixes to be included in 1.9.x will have to be approved by the holy
triangle (Bolek, Bill and myself).

The exceptions are:

* Admin CLI - additions required for testing Admin REST APIs
* Documentation - this will most likely be moved to GitBook for 1.9.3
release
* Testsuite

On-wards to 2.x (with a slight detour to Testland and Documentation City)!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160414/434bac74/attachment.html 

From guus.der.kinderen at gmail.com  Thu Apr 14 06:03:53 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Thu, 14 Apr 2016 12:03:53 +0200
Subject: [keycloak-dev] Bug in UI?
In-Reply-To: <570E5723.7060202@redhat.com>
References: <CAMJaV9mo13KS+HVFyJzcmxcC0noPs-yDwkvxDJZaSjUT7o+6XA@mail.gmail.com>
	<CAM5SUC6MHX2Anrof0s6VyD8cED6tBXnq8Jhx5n6aONpDGRW9tA@mail.gmail.com>
	<CAMJaV9krMEeLt-0P=CjB+XA86fQKrbcvr4sjvkymupVa9SVzbw@mail.gmail.com>
	<570E5723.7060202@redhat.com>
Message-ID: <CAMJaV9k4NUk9yV4S2bK-WuqscJDXW6vuPTNtjEb019kzVM4GMg@mail.gmail.com>

I pulled in the latest changes on the 1.9 branch (I'm now
at 18cc0fdaf3a1dcdfe465e43af096f882eb7bb74a) and retried. The problem does
no longer appear.

 - Guus

On 13 April 2016 at 16:26, Marek Posolda <mposolda at redhat.com> wrote:

> Maybe if you clear browser cache it will help?
>
> We have version in URI of static resources (CSS, HTML, freemarker
> templates etc), so if you work just with released versions like
> "1.8.0.Final" or "1.9.1.Final", the browser cache is not an issue as it's
> different URI for each version. But you're doing some development and
> building KC from sources, so if there are changes, the version is still
> "1.9.2-SNAPSHOT", hence you can see stale content of some file through your
> browser cache.
>
> Marek
>
>
> On 12/04/16 17:12, Guus der Kinderen wrote:
>
> Thanks for the feedback. I didn't try master yet, because I will be
> deploying the upcoming 1.9.2 (master is currently at 2.0.0).
>
>  - Guus
>
> On 12 April 2016 at 17:03, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> Hi Guus, everything is working here for me. Maybe you should try it
>> against the latest changes on master?
>>
>> On Tue, Apr 12, 2016 at 7:10 AM Guus der Kinderen <
>> guus.der.kinderen at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I did not try to reproduce this on master branch, but got it twice now
>>> on 1.9.x. The branch HEAD is commit b01f522acea6b6c5c6f487dc626a24ca928da77d
>>>
>>> After I build the distribution...
>>>
>>> $ mvn clean install -DskipTests -Pdistribution
>>>
>>>
>>> ... extract the distribution ...
>>>
>>> $ cd /distribution/server-dist/target/
>>> $ tar zxvf keycloak-1.9.2.Final-SNAPSHOT.tar.gz
>>>
>>>
>>> ... and start a standalone instance ...
>>>
>>> $ cd /keycloak-1.9.2.Final-SNAPSHOT/bin
>>> $ ./standalone.sh
>>>
>>> ... open the webpage at  <http://localhost:8080/auth>
>>> http://localhost:8080/auth
>>> ... create a new user
>>> ... login to the administration console with that user
>>> ... go to the list of clients
>>> ... and open (or click 'edit') on any of the clients
>>>
>>> Then the webpage that I'm looking at appears to be broken. I'm looking
>>> at the template itself, I think.
>>>
>>> Is this me, or can someone reproduce this?
>>>
>>>  - Guus
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160414/83cd4a46/attachment-0001.html 

From lball at redhat.com  Thu Apr 14 09:15:04 2016
From: lball at redhat.com (Lance Ball)
Date: Thu, 14 Apr 2016 09:15:04 -0400
Subject: [keycloak-dev] Adapter Versioning
In-Reply-To: <CAJgngAf_snX0MS6sNQ2rSGU7phcbZFXF8yNB2-OSrCyWCKe_Tw@mail.gmail.com>
References: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
	<CAJgngAecnFvfq-bRvGQ1ikvpNcJnddHphAqsLYxFyPNqKacO+w@mail.gmail.com>
	<CABRDmicvhtVtV3UzwqYVP6gb=8YhgRaGHVAWOTXvxKN9bCJ=PA@mail.gmail.com>
	<CAJgngAf_snX0MS6sNQ2rSGU7phcbZFXF8yNB2-OSrCyWCKe_Tw@mail.gmail.com>
Message-ID: <CABRDmid9hAmq9+AJyDsAzM6XGrm6BqD-guHN3cW1ZbtJiTj6Ew@mail.gmail.com>

Stian

Thanks for being so patient with my pushback. :)

On Thu, Apr 14, 2016 at 12:53 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Adding list back
>
> On 13 April 2016 at 21:27, Lance Ball <lball at redhat.com> wrote:
>>
>>
>> I'll take your word for it, but I honestly don't see how pushing a new
>> release of _everything_ can possibly be easier than, for example `npm
>> publish` for a single artifact.
>>
>
> Releasing everything is going to be a "single" button click. Having the
> ability to release micro releases of adapters may be something to consider
> in the future if it does indeed become a problem.
>

Obviously, I agree that micro releases would be good - but I understand
your position. All of this is hypothetical at this point anyway, since the
node adapter bits I care most about are not yet full citizens and we have a
little time to get all of our ducks in a row.

2) There is no change in the adapter between releases of Keycloak server.
>>>> In this case, it's not necessarily a problem to release a new adapter
>>>> version, but it seems noisy and pointless if the bits are exactly the same.
>>>>
>>>
>>> The plan is to have release notes that cover which adapters have changed
>>> and which are required to upgrade (either because backwards compatibility
>>> is broken with the server or due to a security fix)
>>>
>>
>> But how is "Keycloak 2.7.0 works with foo-adapter 1.9.1 and greater" any
>> better than "foo-adapter 1.9.1 works with Keycloak 1.9.1 and greater"? The
>> first scenario is what will happen if adapters march in lockstep with
>> Keycloak server, and the second is what will happen if they are released
>> only when necessary. In either case, it is possible to be running different
>> version numbers for foo-adapter and Keycloak server and still be functional.
>>
>
> Being able to grab same version of everything is nice. Being able to not
> have to upgrade everything is nice.
>
> Having to figure out what version belongs to what as a first time adapter
> or when adding a new adapter is not so nice.
>
> Having to figure out what the version is going to be for each individual
> bit when we are doing a collective release is not so nice. Having different
> release cycles, etc, etc.. is not so nice. We are a small team with a large
> amount of work so we can afford to do this as it's additional time spent
> doing releases, which we will be doing every 6 weeks!! so we want to reduce
> the pain of doing a release as much as possible.
>

Absolutely - I understand. We went through a lot of this soul searching
with WildFly Swarm recently, and ended up allowing for separate versioning
between "core" and "non-core" pieces of the project. There's not a lot of
data to go on yet, so we'll see how that turns out. But in this case,
wouldn't the most recent Keycloak server always just use the latest version
of a given adapter for any new release?

Lance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160414/c5df1f4b/attachment.html 

From sthorger at redhat.com  Thu Apr 14 10:00:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Apr 2016 16:00:43 +0200
Subject: [keycloak-dev] Adapter Versioning
In-Reply-To: <CABRDmid9hAmq9+AJyDsAzM6XGrm6BqD-guHN3cW1ZbtJiTj6Ew@mail.gmail.com>
References: <CABRDmidq3VaFUeEA6uhrxXZD0Rv3GJgAdQ4Y6bXBgt1RZs7jag@mail.gmail.com>
	<CAJgngAecnFvfq-bRvGQ1ikvpNcJnddHphAqsLYxFyPNqKacO+w@mail.gmail.com>
	<CABRDmicvhtVtV3UzwqYVP6gb=8YhgRaGHVAWOTXvxKN9bCJ=PA@mail.gmail.com>
	<CAJgngAf_snX0MS6sNQ2rSGU7phcbZFXF8yNB2-OSrCyWCKe_Tw@mail.gmail.com>
	<CABRDmid9hAmq9+AJyDsAzM6XGrm6BqD-guHN3cW1ZbtJiTj6Ew@mail.gmail.com>
Message-ID: <CAJgngAffoT5K5rdZUzMY7PrN4W_MJqKrPrJKix6+ayc1sXN5kA@mail.gmail.com>

On 14 April 2016 at 15:15, Lance Ball <lball at redhat.com> wrote:

> Stian
>
> Thanks for being so patient with my pushback. :)
>
> On Thu, Apr 14, 2016 at 12:53 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Adding list back
>>
>> On 13 April 2016 at 21:27, Lance Ball <lball at redhat.com> wrote:
>>>
>>>
>>> I'll take your word for it, but I honestly don't see how pushing a new
>>> release of _everything_ can possibly be easier than, for example `npm
>>> publish` for a single artifact.
>>>
>>
>> Releasing everything is going to be a "single" button click. Having the
>> ability to release micro releases of adapters may be something to consider
>> in the future if it does indeed become a problem.
>>
>
> Obviously, I agree that micro releases would be good - but I understand
> your position. All of this is hypothetical at this point anyway, since the
> node adapter bits I care most about are not yet full citizens and we have a
> little time to get all of our ducks in a row.
>

Now that we have someone on the team with NodeJS experience and you guys we
hope to make it a full citizen in 2.x, so only a few months from now :)


>
> 2) There is no change in the adapter between releases of Keycloak server.
>>>>> In this case, it's not necessarily a problem to release a new adapter
>>>>> version, but it seems noisy and pointless if the bits are exactly the same.
>>>>>
>>>>
>>>> The plan is to have release notes that cover which adapters have
>>>> changed and which are required to upgrade (either because backwards
>>>> compatibility is broken with the server or due to a security fix)
>>>>
>>>
>>> But how is "Keycloak 2.7.0 works with foo-adapter 1.9.1 and greater" any
>>> better than "foo-adapter 1.9.1 works with Keycloak 1.9.1 and greater"? The
>>> first scenario is what will happen if adapters march in lockstep with
>>> Keycloak server, and the second is what will happen if they are released
>>> only when necessary. In either case, it is possible to be running different
>>> version numbers for foo-adapter and Keycloak server and still be functional.
>>>
>>
>> Being able to grab same version of everything is nice. Being able to not
>> have to upgrade everything is nice.
>>
>> Having to figure out what version belongs to what as a first time adapter
>> or when adding a new adapter is not so nice.
>>
>> Having to figure out what the version is going to be for each individual
>> bit when we are doing a collective release is not so nice. Having different
>> release cycles, etc, etc.. is not so nice. We are a small team with a large
>> amount of work so we can afford to do this as it's additional time spent
>> doing releases, which we will be doing every 6 weeks!! so we want to reduce
>> the pain of doing a release as much as possible.
>>
>
> Absolutely - I understand. We went through a lot of this soul searching
> with WildFly Swarm recently, and ended up allowing for separate versioning
> between "core" and "non-core" pieces of the project. There's not a lot of
> data to go on yet, so we'll see how that turns out. But in this case,
> wouldn't the most recent Keycloak server always just use the latest version
> of a given adapter for any new release?
>

Not sure what you suggesting, but someone (me) has to click the button to
release everything. That someone needs to know what version everything
should be released as. If everything is released as one version and I can
feed that version into my Jenkins job that releases everything it's much
simpler.


>
> Lance
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160414/a5ccb6fa/attachment.html 

From sthorger at redhat.com  Thu Apr 14 10:36:05 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Apr 2016 16:36:05 +0200
Subject: [keycloak-dev] Keycloak 1.9.2.Final released
Message-ID: <CAJgngAdeDQFv=w4mTYXiWt7TNM1gbM_PdWaUC_nSwqrzUmvR8g@mail.gmail.com>

The team has done an awesome job this time around and we've spent the last
few weeks polishing and fixing! With 141 issues resolved this release takes
us one step closer to having a supported version of Keycloak. For the next
release we will focus on extending our testsuite as well as improving
documentation. If you haven't already upgraded to 1.9.x now is the time!

For the full list of resolved issues check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.2.Final>
and to download the release go to the Keycloak homepage.
<http://www.keycloak.org/downloads>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160414/f14d1d31/attachment.html 

From lball at redhat.com  Thu Apr 14 10:57:04 2016
From: lball at redhat.com (Lance Ball)
Date: Thu, 14 Apr 2016 10:57:04 -0400
Subject: [keycloak-dev] Keycloak 1.9.2.Final released
In-Reply-To: <CAJgngAdeDQFv=w4mTYXiWt7TNM1gbM_PdWaUC_nSwqrzUmvR8g@mail.gmail.com>
References: <CAJgngAdeDQFv=w4mTYXiWt7TNM1gbM_PdWaUC_nSwqrzUmvR8g@mail.gmail.com>
Message-ID: <CABRDmid0BTW3sh3BTi9vBKz48i5Um_yWKAx23df32irsiA=B8A@mail.gmail.com>

Congrats to the team!

On Thursday, April 14, 2016, Stian Thorgersen <sthorger at redhat.com> wrote:

> The team has done an awesome job this time around and we've spent the last
> few weeks polishing and fixing! With 141 issues resolved this release takes
> us one step closer to having a supported version of Keycloak. For the next
> release we will focus on extending our testsuite as well as improving
> documentation. If you haven't already upgraded to 1.9.x now is the time!
>
> For the full list of resolved issues check out JIRA
> <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.2.Final>
> and to download the release go to the Keycloak homepage.
> <http://www.keycloak.org/downloads>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160414/d03fdf17/attachment-0001.html 

From guus.der.kinderen at gmail.com  Thu Apr 14 10:58:04 2016
From: guus.der.kinderen at gmail.com (Guus der Kinderen)
Date: Thu, 14 Apr 2016 16:58:04 +0200
Subject: [keycloak-dev] Keycloak 1.9.2.Final released
In-Reply-To: <CABRDmid0BTW3sh3BTi9vBKz48i5Um_yWKAx23df32irsiA=B8A@mail.gmail.com>
References: <CAJgngAdeDQFv=w4mTYXiWt7TNM1gbM_PdWaUC_nSwqrzUmvR8g@mail.gmail.com>
	<CABRDmid0BTW3sh3BTi9vBKz48i5Um_yWKAx23df32irsiA=B8A@mail.gmail.com>
Message-ID: <CAMJaV9kLBMmd4jdfbc5jYRiHurto+ptD=+R8OaR=Q2eqEimNjw@mail.gmail.com>

\o/

On 14 April 2016 at 16:57, Lance Ball <lball at redhat.com> wrote:

> Congrats to the team!
>
>
> On Thursday, April 14, 2016, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> The team has done an awesome job this time around and we've spent the
>> last few weeks polishing and fixing! With 141 issues resolved this release
>> takes us one step closer to having a supported version of Keycloak. For the
>> next release we will focus on extending our testsuite as well as improving
>> documentation. If you haven't already upgraded to 1.9.x now is the time!
>>
>> For the full list of resolved issues check out JIRA
>> <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.2.Final>
>> and to download the release go to the Keycloak homepage.
>> <http://www.keycloak.org/downloads>
>>
>
> _______________________________________________
> 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/20160414/acd48ac8/attachment.html 

From jdennis at redhat.com  Thu Apr 14 20:55:56 2016
From: jdennis at redhat.com (John Dennis)
Date: Thu, 14 Apr 2016 20:55:56 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
Message-ID: <57103C1C.8060806@redhat.com>

I could use some help from your SAML developers because I'm seeing what 
appears to be incorrect behavior.

During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent 
using the HTTP-Redirect binding. The AuthnRequest specifies a 
AssertionConsumerServiceURL for the SP which has the HTTP-POST binding. 
When Keycloak responds with the Assertion in the SAMLResponse it 
incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST 
binding (specified in both the AuthnRequest and the SP metadata). This 
causes a failure because the endpoint for the SP's 
AssertionConsumerServiceURL only expects HTTP-POST, the resulting error 
is an invalid HTTP method failure.

I also noticed that when I used the Web UI to examine the SP metadata 
(Installation tab of the realm client, selecting the "SAML Metadata 
SPSSODescriptor" format) that it did not match the SP metadata that had 
been loaded using the client registration service. Not only wasn't it 
the exact same metadata, but specifically it was missing several of the 
endpoints the SP declared in it's metadata. Why isn't the metadata the 
same and why did Keycloak drop essential endpoint/binding information?

Thanks,

-- 
John

From carreraariel at gmail.com  Thu Apr 14 23:24:28 2016
From: carreraariel at gmail.com (Ariel Carrera)
Date: Fri, 15 Apr 2016 00:24:28 -0300
Subject: [keycloak-dev] Keycloak 1.9.2.Final released
In-Reply-To: <CAMJaV9kLBMmd4jdfbc5jYRiHurto+ptD=+R8OaR=Q2eqEimNjw@mail.gmail.com>
References: <CAJgngAdeDQFv=w4mTYXiWt7TNM1gbM_PdWaUC_nSwqrzUmvR8g@mail.gmail.com>
	<CABRDmid0BTW3sh3BTi9vBKz48i5Um_yWKAx23df32irsiA=B8A@mail.gmail.com>
	<CAMJaV9kLBMmd4jdfbc5jYRiHurto+ptD=+R8OaR=Q2eqEimNjw@mail.gmail.com>
Message-ID: <CAFzO_6cicG1mAP1AEdKm1w+8L5Ci0pt0_O2Xq6oeuDMpV+bx+g@mail.gmail.com>

Congrats!
+1
El 14/4/2016 11:58, "Guus der Kinderen" <guus.der.kinderen at gmail.com>
escribi?:

> \o/
>
> On 14 April 2016 at 16:57, Lance Ball <lball at redhat.com> wrote:
>
>> Congrats to the team!
>>
>>
>> On Thursday, April 14, 2016, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> The team has done an awesome job this time around and we've spent the
>>> last few weeks polishing and fixing! With 141 issues resolved this release
>>> takes us one step closer to having a supported version of Keycloak. For the
>>> next release we will focus on extending our testsuite as well as improving
>>> documentation. If you haven't already upgraded to 1.9.x now is the time!
>>>
>>> For the full list of resolved issues check out JIRA
>>> <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.2.Final>
>>> and to download the release go to the Keycloak homepage.
>>> <http://www.keycloak.org/downloads>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160415/f0829995/attachment.html 

From thomas.darimont at googlemail.com  Fri Apr 15 00:37:09 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 15 Apr 2016 06:37:09 +0200
Subject: [keycloak-dev] Keycloak 1.9.2.Final released
In-Reply-To: <CAJgngAdeDQFv=w4mTYXiWt7TNM1gbM_PdWaUC_nSwqrzUmvR8g@mail.gmail.com>
References: <CAJgngAdeDQFv=w4mTYXiWt7TNM1gbM_PdWaUC_nSwqrzUmvR8g@mail.gmail.com>
Message-ID: <CAK-7U1js32PSyWOe-UAnxm4oYt+AT4=cKxNADZuQVqcXtqQwhg@mail.gmail.com>

Congratulations! We'll done!
Am 14.04.2016 4:36 nachm. schrieb "Stian Thorgersen" <sthorger at redhat.com>:

> The team has done an awesome job this time around and we've spent the last
> few weeks polishing and fixing! With 141 issues resolved this release takes
> us one step closer to having a supported version of Keycloak. For the next
> release we will focus on extending our testsuite as well as improving
> documentation. If you haven't already upgraded to 1.9.x now is the time!
>
> For the full list of resolved issues check out JIRA
> <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.2.Final>
> and to download the release go to the Keycloak homepage.
> <http://www.keycloak.org/downloads>
>
> _______________________________________________
> 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/20160415/b8505be7/attachment.html 

From ssilvert at redhat.com  Fri Apr 15 08:47:11 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 15 Apr 2016 08:47:11 -0400
Subject: [keycloak-dev] Migrate testsuite
In-Reply-To: <CAJ_ZAU3w_s54kfC8npNg7VeM3Y+sCH83W9xeJM+Br_eWrE3zoA@mail.gmail.com>
References: <CAJgngAcYaU4AxYY+EqGvNEF2=HsBDJdzdCVcUVTbeJowF4NSMQ@mail.gmail.com>
	<CAJgngAdv8x8uSY5hAct48Yc7a4Bv_ycdAXShMSZd7zdq9MqBuA@mail.gmail.com>
	<57050A7F.5040107@redhat.com>
	<CAJgngAfJMYvX_ep5QHSZmz3=Q+mYqcWyHy5oQy-ioYhqptuHYA@mail.gmail.com>
	<57056172.80403@redhat.com>
	<CAJgngAdqdnUwJEdE=jTObpQnKUEQw5KwzBc89n_kcPZzLiMSLQ@mail.gmail.com>
	<57063CE8.8070006@redhat.com>
	<CAJ_ZAU1zy9+U6atAUvwJ=C6DNtLSxcKbAEeU-WrjWWozG2QStQ@mail.gmail.com>
	<CAJgngAcpQ6nkFSCJHfCH_6Uy1pMj75DCfsOMa4gtmVAADxH0OQ@mail.gmail.com>
	<CAJ_ZAU0=vvP-e2G6zqFesVy1CP6dZNmFnrezSBst0u9J=27GYA@mail.gmail.com>
	<CAJgngAfsoaF=AswHdpRZcJwhm5PC-XN=-qdFPx4E=4pWHv9xyg@mail.gmail.com>
	<5706987B.8010002@redhat.com>
	<CAJgngAcY+r14eCikhyEfX2LE99FkeSRQ2Jxo-Pgov2+r910-tw@mail.gmail.com>
	<CAJ_ZAU05EkmfGCGNhzGPHMZ6djWM31VN-7XZzELCtCN=e5978Q@mail.gmail.com>
	<570D1F49.90103@redhat.com> <570D42EF.6050401@redhat.com>
	<CAJ_ZAU3w_s54kfC8npNg7VeM3Y+sCH83W9xeJM+Br_eWrE3zoA@mail.gmail.com>
Message-ID: <5710E2CF.1070603@redhat.com>

OAuthClient is now migrated to the new testsuite and merged to master.  
PR for 1.9.x is pending.

Also new is an abstract base class that should be helpful for migrating 
tests.

org.keycloak.testsuite.TestRealmKeycloakTest provides a method called 
configureTestRealm(RealmRepresentation testRealm). Override this method 
to do the same kind of configuration performed in the old testsuite.  
(Note: "testRealm" was referred to as "appRealm" in the old testsuite.)

OLD TESTSUITE:
https://github.com/keycloak/keycloak/blob/1.8.x/testsuite/integration/src/test/java/org/keycloak/testsuite/oauth/TokenIntrospectionTest.java#L63-L85

EQUIVALENT CODE IN NEW TESTSUITE:
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/oauth/TokenIntrospectionTest.java#L80-L102

On 4/12/2016 3:11 PM, Bruno Oliveira wrote:
> Nice! Meanwhile answering my own question, seems like
> transforAccessToken is required for that test case work.
>
> On Tue, Apr 12, 2016 at 3:48 PM, Stan Silvert <ssilvert at redhat.com> wrote:
>> On 4/12/2016 12:16 PM, Stan Silvert wrote:
>>> On 4/12/2016 10:38 AM, Bruno Oliveira wrote:
>>>> Good morning,
>>>>
>>>> I'm looking at this test case
>>>>
>>>> https://gist.github.com/abstractj/8d3f1ca74a0dfb4f58f7810c519c6272#file-accesstokentest-java-L90
>>>>
>>>> Although, it fails here
>>>>
>>>> https://gist.github.com/abstractj/8d3f1ca74a0dfb4f58f7810c519c6272#file-accesstokentest-java-L112
>>>>
>>>> My feeling is the fact that I don't have this method
>>>>
>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/services/src/main/java/org/keycloak/protocol/oidc/mappers/RoleNameMapper.java#L91
>>>>
>>>> My question is: Is this something that could be solved with
>>>> OAuthClient or is just the matter of migrate transformAccessToken?
>>> I don't know the answer, but I can tell you where I am with OAuthClient.
>>> It appears to be all working now.
>>>
>>> I've migrated TokenIntrospectionTest and ClientTest, which use several,
>>> but not all, of the OAuthClient methods.  All of the tests in those classes
>>> will pass.
>>>
>>> However, TokenIntrospectionTest will only pass if you run each test
>>> individually.  The reason they won't run as a group is because
>>> AssertEvents.clear() is not working.  It took awhile but I finally figured
>>> out why.  The problem is that AssertEvents.clear() is trying to call
>>> realmResource.clearEvents().  But there is a servlet filter installed and
>>> that is where the events are actually read from.    So
>>> realmResource.clearEvents() doesn't have any effect on the event cache being
>>> read during the test.
>>>
>>> There are two ways we could fix this.  One is to get rid of the filter and
>>> make AssertEvents completely rely on the adminClient. The other way is to
>>> add a clear() method to EventListenerProvider. That way, all event listeners
>>> will be notified to clear out their event caches.
>> Actually, there is a third option.  I added a second "command" to the
>> AssertEventsServletFilter.  Now it can respond to both /event-queue and
>> /clear-event-queue.  Updated AssertEvents to use clear-event-queue and
>> everything now works.  PR coming soon.
>>
>>
>>> Bruno, for now just be aware that AssertEvents.clear() isn't working.
>>>>
>>>> On Thu, Apr 7, 2016 at 2:32 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>>
>>>>> On 7 April 2016 at 19:27, Stan Silvert <ssilvert at redhat.com> wrote:
>>>>>> On 4/7/2016 10:52 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>> The testsuite before calls the model to change config as required. This
>>>>>> should just be changed to use admin endpoints. Isn't that all that's
>>>>>> required?
>>>>>>
>>>>>> I'm not sure.  The test-app displays a link to account management.
>>>>>> Presumably, one or more tests are relying on that particular link.
>>>>>> Plus,
>>>>>> since tests would then be relying on a different app (admin console),
>>>>>> there
>>>>>> would be cascading changes to the realm configuration and probably the
>>>>>> tests
>>>>>> themselves.
>>>>>>
>>>>>> See below.
>>>>>>
>>>>>>
>>>>>> On 7 April 2016 at 16:40, Bruno Oliveira <abstractj at redhat.com> wrote:
>>>>>>> Sorry about the lack of details. I'm looking more precisely at
>>>>>>> AccessTokenTest and migrating this method[1] which does not depends on
>>>>>>> OAuthClient.
>>>>>>>
>>>>>>> The "test-app" that I mentioned is this one[2].
>>>>>> Rather than refactoring OAuthClient and possibly any code that uses it,
>>>>>> I'm proposing to move forward and just deploy the little test-app when
>>>>>> the
>>>>>> server starts up.
>>>>>>
>>>>>> I'm worried about breaking these tests in unknown and possibly
>>>>>> undetectable ways.  Stian, if you've got time to look it all over then
>>>>>> we
>>>>>> can do something different, but I don't think Bruno and I know these
>>>>>> tests
>>>>>> well enough to change it safely.
>>>>>>
>>>>>> I'd rather make sure we can port the tests as-is without changes.  It
>>>>>> won't be hard to let the Keycloak server deploy the little servlet.
>>>>>> That
>>>>>> will at least let us move forward.  We can always change it later.
>>>>>>
>>>>>> Sound ok?
>>>>>
>>>>> Oki, but instead of deploying a WAR to Keycloak, something which is not
>>>>> supported, so may not work in the future, add a custom REST endpoint
>>>>> like
>>>>> what I did for the TimeOffset
>>>>>
>>>>>>> [1] -
>>>>>>>
>>>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/testsuite/integration/src/test/java/org/keycloak/testsuite/oauth/AccessTokenTest.java#L399
>>>>>>> [2] -
>>>>>>>
>>>>>>> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/testrealm.json#L102
>>>>>>>
>>>>>>> On Thu, Apr 7, 2016 at 11:32 AM, Stian Thorgersen
>>>>>>> <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 7 April 2016 at 16:28, Bruno Oliveira <abstractj at redhat.com>
>>>>>>>> wrote:
>>>>>>>>> I will also try to take a look later today. I have more questions of
>>>>>>>>> course, actually I have to enable direct access grant for my
>>>>>>>>> "test-app".
>>>>>>>>
>>>>>>>> What's your "test-app"?
>>>>>>>>
>>>>>>>>> My question is: to not mess with other tests, should I just add a
>>>>>>>>> new
>>>>>>>>> client to testrealm.json or it's ok to do some changes as long as it
>>>>>>>>> does not break other tests?
>>>>>>>>
>>>>>>>> Depends on what your "test-app" is ;)
>>>>>>>>
>>>>>>>>> On Thu, Apr 7, 2016 at 7:56 AM, Stan Silvert <ssilvert at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>> On 4/7/2016 12:36 AM, Stian Thorgersen wrote:
>>>>>>>>>>
>>>>>>>>>> It can probably fairly easily be converted to not requiring
>>>>>>>>>> anything
>>>>>>>>>> to
>>>>>>>>>> be
>>>>>>>>>> deployed and instead just send to an invalid url. I can take a look
>>>>>>>>>> at
>>>>>>>>>> that
>>>>>>>>>> if you want?
>>>>>>>>>>
>>>>>>>>>> Yes, take a look and let me know what you think about that.  It
>>>>>>>>>> would
>>>>>>>>>> improve the design of it.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6 April 2016 at 21:20, Stan Silvert <ssilvert at redhat.com> wrote:
>>>>>>>>>>> On 4/6/2016 9:26 AM, Stian Thorgersen wrote:
>>>>>>>>>>>
>>>>>>>>>>> The new one is just a simple method so I don't see the issue in
>>>>>>>>>>> merging
>>>>>>>>>>> the two (once the old is working that is)
>>>>>>>>>>>
>>>>>>>>>>> I over-simplified my question, which is why I was wanting to chat.
>>>>>>>>>>> But,
>>>>>>>>>>> I'm too far in the weeds to talk right now.
>>>>>>>>>>>
>>>>>>>>>>> This is getting a bit hairy because the old OAuthClient relies on
>>>>>>>>>>> the
>>>>>>>>>>> fact
>>>>>>>>>>> that there is a little application deployed with context
>>>>>>>>>>> http://localhost:8081/app.  So apparently, I've got to convert the
>>>>>>>>>>> undertow
>>>>>>>>>>> DeploymentInfo into a Shirkwrap WebArchive and let arquillian
>>>>>>>>>>> deploy
>>>>>>>>>>> the
>>>>>>>>>>> little app.
>>>>>>>>>>>
>>>>>>>>>>> But unless you guys can think of an easier solution I've got quite
>>>>>>>>>>> a
>>>>>>>>>>> bit
>>>>>>>>>>> of work to do before we discuss unification.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 6 April 2016 at 15:09, Stan Silvert <ssilvert at redhat.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> I've found a problem with the migrated OAuth client and I've been
>>>>>>>>>>>> trying
>>>>>>>>>>>> to work on that.
>>>>>>>>>>>>
>>>>>>>>>>>> The thing I wanted to discuss yesterday was about unification of
>>>>>>>>>>>> the
>>>>>>>>>>>> old
>>>>>>>>>>>> and new OAuth clients.  But that's a moot point as long as the
>>>>>>>>>>>> old
>>>>>>>>>>>> one
>>>>>>>>>>>> isn't
>>>>>>>>>>>> fully working with the new testsuite.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/6/2016 8:03 AM, Stian Thorgersen wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Do you and Stan still want a chat? If so I can do it now
>>>>>>>>>>>>
>>>>>>>>>>>> On 6 Apr 2016 13:46, "Bruno Oliveira" <abstractj at redhat.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Great news!
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Apr 6, 2016 at 6:24 AM, Stian Thorgersen
>>>>>>>>>>>>> <sthorger at redhat.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Bruno and Stan, thanks to Pedro we now have the ability to add
>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>> REST endpoints to Keycloak [1]. Also, thanks to Marko we can
>>>>>>>>>>>>>> add
>>>>>>>>>>>>>> already add
>>>>>>>>>>>>>> custom providers to the Arquillian testsuite. Once [2] is
>>>>>>>>>>>>>> merged
>>>>>>>>>>>>>> (in
>>>>>>>>>>>>>> an hour
>>>>>>>>>>>>>> or so) tests can easily set the time offset on the server. I
>>>>>>>>>>>>>> added a
>>>>>>>>>>>>>> temporary test that does exactly that [3].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There's a bit of clean-up to do with assert events and the
>>>>>>>>>>>>>> custom
>>>>>>>>>>>>>> testsuite providers, but Marko can do that when he gets back
>>>>>>>>>>>>>> [4].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] https://issues.jboss.org/browse/KEYCLOAK-2262
>>>>>>>>>>>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-2590
>>>>>>>>>>>>>> [3] org.keycloak.testsuite.TempSetTimeOffsetTest
>>>>>>>>>>>>>> [4] https://issues.jboss.org/browse/KEYCLOAK-2755
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4 April 2016 at 14:30, Bruno Oliveira <abstractj at redhat.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Perfect and yes for Drone. That already helps with my n00bish
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>> the test suite.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 9:26 AM, Stian Thorgersen
>>>>>>>>>>>>>>> <sthorger at redhat.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> KeycloakRule should be removed and replaced with extending
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> AbstractKeycloakTest. OAuthClient should be ported, but Drone
>>>>>>>>>>>>>>>> uses
>>>>>>>>>>>>>>>> WebDriver
>>>>>>>>>>>>>>>> under the covers right? So it's just about changing how it's
>>>>>>>>>>>>>>>> injected.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4 April 2016 at 14:19, Bruno Oliveira
>>>>>>>>>>>>>>>> <abstractj at redhat.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> I know we have a meeting about it today, but I have a
>>>>>>>>>>>>>>>>> question ?
>>>>>>>>>>>>>>>>> thinking about AccessTokenTest[1]. Should we keep the
>>>>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>>>>> structure as
>>>>>>>>>>>>>>>>> is and just replace WebDriver by Drone?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For example, from my poor understanding KeycloakRule,
>>>>>>>>>>>>>>>>> WebRule,
>>>>>>>>>>>>>>>>> OAuthClient should be migrated to the new test suite and the
>>>>>>>>>>>>>>>>> bits
>>>>>>>>>>>>>>>>> refering
>>>>>>>>>>>>>>>>> to WebDriver ported to Drone[2].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Am I totally wrong?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [1] -
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/testsuite/integration/src/test/java/org/keycloak/testsuite/oauth/AccessTokenTest.java#L96
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [2] - https://docs.jboss.org/author/display/ARQ/Drone
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 8:55 AM, Bruno Oliveira
>>>>>>>>>>>>>>>>> <abstractj at redhat.com> wrote:
>>>>>>>>>>>>>>>>>> Thank you Stan, will give it a try
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Apr 4, 2016 at 8:46 AM, Stan Silvert
>>>>>>>>>>>>>>>>>> <ssilvert at redhat.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> Bruno,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Here is what I've done so far. Still have 9 migrated tests
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> this package that don't pass.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://github.com/ssilvert/keycloak/tree/migrate-admin/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/migrated/admin
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AbstractClientTest is where most of the adaptation to the
>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> test
>>>>>>>>>>>>>>>>>>> suite happens.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Stan
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 4/1/2016 11:04 AM, Bruno Oliveira wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That makes sense. I will check your commits and try to
>>>>>>>>>>>>>>>>>>> adapt to
>>>>>>>>>>>>>>>>>>> my
>>>>>>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks Stan
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Apr 1, 2016 at 10:24 AM, Stan Silvert
>>>>>>>>>>>>>>>>>>> <ssilvert at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>> Having never done this before, we don't have any
>>>>>>>>>>>>>>>>>>>> guidelines.
>>>>>>>>>>>>>>>>>>>> But
>>>>>>>>>>>>>>>>>>>> I can tell you how I am approaching this at the moment.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't want to touch the actual test code if possible.
>>>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>>>> reason is that there is no way I could fully understand
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> intent of the
>>>>>>>>>>>>>>>>>>>> original author.  Changes to the test code could yield
>>>>>>>>>>>>>>>>>>>> false
>>>>>>>>>>>>>>>>>>>> positives and
>>>>>>>>>>>>>>>>>>>> we would end up with code that doesn't actually test what
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> was intended to
>>>>>>>>>>>>>>>>>>>> test.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So I copy over the original test class and get rid of the
>>>>>>>>>>>>>>>>>>>> annotations that pertain to the old environment.   Then I
>>>>>>>>>>>>>>>>>>>> write adapter code
>>>>>>>>>>>>>>>>>>>> that lets the test code remain unchanged while calling
>>>>>>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>>>>> the new
>>>>>>>>>>>>>>>>>>>> environment.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Of course, there is risk in that approach as well, but it
>>>>>>>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>>>>>>>> less than if I tried to modify the original test methods.
>>>>>>>>>>>>>>>>>>>> And
>>>>>>>>>>>>>>>>>>>> it seems to
>>>>>>>>>>>>>>>>>>>> be working well as about 75% of my tests are passing
>>>>>>>>>>>>>>>>>>>> unchanged
>>>>>>>>>>>>>>>>>>>> with only a
>>>>>>>>>>>>>>>>>>>> minimal bit of adapter code written so far.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For this reason, I rejected extending AbstractAuthTest in
>>>>>>>>>>>>>>>>>>>> favor
>>>>>>>>>>>>>>>>>>>> of my own abstract class that just extends
>>>>>>>>>>>>>>>>>>>> AbstractKeycloakTest.   That new
>>>>>>>>>>>>>>>>>>>> abstract class is where the adapter code lives.  I also
>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> concerns about
>>>>>>>>>>>>>>>>>>>> duplication of effort so hopefully at some point I can
>>>>>>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>>>>>>>> generic code
>>>>>>>>>>>>>>>>>>>> that applies to all the migrated tests instead of just
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> ones I'm working
>>>>>>>>>>>>>>>>>>>> on.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But by then, we might be all done anyway...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 4/1/2016 6:23 AM, Bruno Oliveira wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Good morning, I have a question to prevent duplicated
>>>>>>>>>>>>>>>>>>>> work.
>>>>>>>>>>>>>>>>>>>> Taking as an example AccessTokenTest[1].
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In order to execute the tests we have an user
>>>>>>>>>>>>>>>>>>>> "no-permissions"
>>>>>>>>>>>>>>>>>>>> with the role "user". Add an user is easy if I extend
>>>>>>>>>>>>>>>>>>>> AbstractAuthTest[2],
>>>>>>>>>>>>>>>>>>>> at the same time we don't have any method to assign the
>>>>>>>>>>>>>>>>>>>> role
>>>>>>>>>>>>>>>>>>>> "user".
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> To follow the correct guidelines. Should I extend
>>>>>>>>>>>>>>>>>>>> AbstractAuthTest and add the proper method to assign
>>>>>>>>>>>>>>>>>>>> roles
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the same
>>>>>>>>>>>>>>>>>>>> class? Or this is definitely wrong?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [1] -
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/c7a8742a368bd8d76301145b08bb1e4af1b010e9/testsuite/integration/src/test/java/org/keycloak/testsuite/oauth/AccessTokenTest.java#L96
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [2] -
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/blob/7c64ab228b7c95646c54caa4e1562512d18bd4e2/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/AbstractAuthTest.java#L43-L43
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 3:26 PM, Stian Thorgersen
>>>>>>>>>>>>>>>>>>>> <sthorger at redhat.com> wrote:
>>>>>>>>>>>>>>>>>>>>> We need to co-ordinate who migrate which tests. I'm not
>>>>>>>>>>>>>>>>>>>>> quite
>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>> available this week, but will be checking email at least
>>>>>>>>>>>>>>>>>>>>> once
>>>>>>>>>>>>>>>>>>>>> a day. I will
>>>>>>>>>>>>>>>>>>>>> be fully operational next week.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Prerequisites to migrating tests are:
>>>>>>>>>>>>>>>>>>>>> * Port assert events (there's a PR from Marko on this
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>>>>>> to review and merge it)
>>>>>>>>>>>>>>>>>>>>> * Ability to set time offset through admin endpoints
>>>>>>>>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>>>>>>>>> required for expirations or other time sensitive tests)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Once those are done we can start migrating tests. To
>>>>>>>>>>>>>>>>>>>>> prevent
>>>>>>>>>>>>>>>>>>>>> multiple folks porting the same tests, here's your
>>>>>>>>>>>>>>>>>>>>> initial
>>>>>>>>>>>>>>>>>>>>> list to port
>>>>>>>>>>>>>>>>>>>>> (packages in
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/tree/master/testsuite/integration/src/test/java/org/keycloak/testsuite):
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> * Stan - admin (these may be duplicates in the new admin
>>>>>>>>>>>>>>>>>>>>> endpoints tests), actions
>>>>>>>>>>>>>>>>>>>>> * Bruno - oauth, forms
>>>>>>>>>>>>>>>>>>>>> * Bolek - account
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That's right, we're so behind with tests that even the
>>>>>>>>>>>>>>>>>>>>> engineering manager has to start coding.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Let's use this thread as a place to discuss progress and
>>>>>>>>>>>>>>>>>>>>> issues
>>>>>>>>>>>>>>>>>>>>> around migrating the tests.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -
>>>>>>>>>>>>> abstractj
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> abstractj
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> -
>>>>>>> abstractj
>>>>>>
>>>>>>
>>>>
>
>


From jdennis at redhat.com  Fri Apr 15 10:04:55 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 15 Apr 2016 10:04:55 -0400
Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;
	ECP won't work
Message-ID: <5710F507.8040200@redhat.com>

Using keycloak-1.9.0.Final only the HTTP-POST and HTTP-Redirect bindings 
are advertised in the IdP Metadata for SingleSignOnService.

The SOAP SingleSignOnService was added when it was discovered to be 
missing in the 1.8 cycle, or so I thought. Did it get added in a 
different release or did it get lost somehow?

Anyway, it's really important. SAML ECP won't work unless you advertise 
support for it.


-- 
John

From psilva at redhat.com  Fri Apr 15 12:40:43 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Apr 2016 12:40:43 -0400 (EDT)
Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;
 ECP won't work
In-Reply-To: <5710F507.8040200@redhat.com>
References: <5710F507.8040200@redhat.com>
Message-ID: <1336365939.51656522.1460738443794.JavaMail.zimbra@redhat.com>

Hi John,

    I think we never added SOAP to IdP metadata. I pretty sure we did all those ECP tests without it.

    In any case, I'm going to change IdP Metadata to advertise the SOAP binding.

Regards.
Pedro Igor

----- Original Message -----
From: "John Dennis" <jdennis at redhat.com>
To: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>, "Adam Young" <ayoung at redhat.com>
Sent: Friday, April 15, 2016 11:04:55 AM
Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;	ECP won't work

Using keycloak-1.9.0.Final only the HTTP-POST and HTTP-Redirect bindings 
are advertised in the IdP Metadata for SingleSignOnService.

The SOAP SingleSignOnService was added when it was discovered to be 
missing in the 1.8 cycle, or so I thought. Did it get added in a 
different release or did it get lost somehow?

Anyway, it's really important. SAML ECP won't work unless you advertise 
support for it.


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

From jdennis at redhat.com  Fri Apr 15 12:44:32 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 15 Apr 2016 12:44:32 -0400
Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;
 ECP won't work
In-Reply-To: <1336365939.51656522.1460738443794.JavaMail.zimbra@redhat.com>
References: <5710F507.8040200@redhat.com>
	<1336365939.51656522.1460738443794.JavaMail.zimbra@redhat.com>
Message-ID: <57111A70.5030009@redhat.com>

On 04/15/2016 12:40 PM, Pedro Igor Silva wrote:
> Hi John,
>
>      I think we never added SOAP to IdP metadata. I pretty sure we did all those ECP tests without it.
>
>      In any case, I'm going to change IdP Metadata to advertise the SOAP binding.
>

Thank you Pedro! Are you going to open a Jira?

> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "John Dennis" <jdennis at redhat.com>
> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>, "Adam Young" <ayoung at redhat.com>
> Sent: Friday, April 15, 2016 11:04:55 AM
> Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;	ECP won't work
>
> Using keycloak-1.9.0.Final only the HTTP-POST and HTTP-Redirect bindings
> are advertised in the IdP Metadata for SingleSignOnService.
>
> The SOAP SingleSignOnService was added when it was discovered to be
> missing in the 1.8 cycle, or so I thought. Did it get added in a
> different release or did it get lost somehow?
>
> Anyway, it's really important. SAML ECP won't work unless you advertise
> support for it.
>
>


-- 
John

From psilva at redhat.com  Fri Apr 15 12:47:14 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Apr 2016 12:47:14 -0400 (EDT)
Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;
 ECP won't work
In-Reply-To: <1336365939.51656522.1460738443794.JavaMail.zimbra@redhat.com>
References: <5710F507.8040200@redhat.com>
	<1336365939.51656522.1460738443794.JavaMail.zimbra@redhat.com>
Message-ID: <2032008930.51658060.1460738834983.JavaMail.zimbra@redhat.com>

Btw, created https://issues.jboss.org/browse/KEYCLOAK-2835.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "John Dennis" <jdennis at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>
Sent: Friday, April 15, 2016 1:40:43 PM
Subject: Re: [keycloak-dev] missing SingleSignOnService SOAP binding; ECP won't work

Hi John,

    I think we never added SOAP to IdP metadata. I pretty sure we did all those ECP tests without it.

    In any case, I'm going to change IdP Metadata to advertise the SOAP binding.

Regards.
Pedro Igor

----- Original Message -----
From: "John Dennis" <jdennis at redhat.com>
To: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>, "Adam Young" <ayoung at redhat.com>
Sent: Friday, April 15, 2016 11:04:55 AM
Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;	ECP won't work

Using keycloak-1.9.0.Final only the HTTP-POST and HTTP-Redirect bindings 
are advertised in the IdP Metadata for SingleSignOnService.

The SOAP SingleSignOnService was added when it was discovered to be 
missing in the 1.8 cycle, or so I thought. Did it get added in a 
different release or did it get lost somehow?

Anyway, it's really important. SAML ECP won't work unless you advertise 
support for it.


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

From psilva at redhat.com  Fri Apr 15 14:07:38 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Apr 2016 14:07:38 -0400 (EDT)
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <57103C1C.8060806@redhat.com>
References: <57103C1C.8060806@redhat.com>
Message-ID: <802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>

Hi John,

    Like we discussed on IRC, KC relies on the ProtocolBinding attribute of an AuthnRequest to decide which response binding to use. We don't support AssertionConsumerServiceURL neither AssertionConsumerServiceIndex. Accordingly with the specs, all those attributes are optional and mutually exclusive. In case ProtocolBinding is not provided, KC chooses on based on how the AutnRequest was sent. Eg.? If sent using POST than use POST to respond.

    Regarding the SP Metadata, I would suggest you to open a JIRA with more details about what you need to get into the SP Metadata and how the mismatch between what you loaded and what is actually published is affecting you.

Regards.
Pedro Igor

----- Original Message -----
From: "John Dennis" <jdennis at redhat.com>
To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Cc: "Nathan Kinder" <nkinder at redhat.com>
Sent: Thursday, April 14, 2016 9:55:56 PM
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding

I could use some help from your SAML developers because I'm seeing what 
appears to be incorrect behavior.

During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent 
using the HTTP-Redirect binding. The AuthnRequest specifies a 
AssertionConsumerServiceURL for the SP which has the HTTP-POST binding. 
When Keycloak responds with the Assertion in the SAMLResponse it 
incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST 
binding (specified in both the AuthnRequest and the SP metadata). This 
causes a failure because the endpoint for the SP's 
AssertionConsumerServiceURL only expects HTTP-POST, the resulting error 
is an invalid HTTP method failure.

I also noticed that when I used the Web UI to examine the SP metadata 
(Installation tab of the realm client, selecting the "SAML Metadata 
SPSSODescriptor" format) that it did not match the SP metadata that had 
been loaded using the client registration service. Not only wasn't it 
the exact same metadata, but specifically it was missing several of the 
endpoints the SP declared in it's metadata. Why isn't the metadata the 
same and why did Keycloak drop essential endpoint/binding information?

Thanks,

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


From psilva at redhat.com  Fri Apr 15 14:15:15 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Apr 2016 14:15:15 -0400 (EDT)
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
Message-ID: <197263616.51691308.1460744115919.JavaMail.zimbra@redhat.com>

What I meant is that ProtocolBinding and AssertionConsumerServiceIndex are mutually exclusive. Since that ACSURL is usually used in conjunction with ProtocolBinding to decide where to redirect to.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "John Dennis" <jdennis at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>
Sent: Friday, April 15, 2016 3:07:38 PM
Subject: Re: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding

Hi John,

    Like we discussed on IRC, KC relies on the ProtocolBinding attribute of an AuthnRequest to decide which response binding to use. We don't support AssertionConsumerServiceURL neither AssertionConsumerServiceIndex. Accordingly with the specs, all those attributes are optional and mutually exclusive. In case ProtocolBinding is not provided, KC chooses on based on how the AutnRequest was sent. Eg.? If sent using POST than use POST to respond.

    Regarding the SP Metadata, I would suggest you to open a JIRA with more details about what you need to get into the SP Metadata and how the mismatch between what you loaded and what is actually published is affecting you.

Regards.
Pedro Igor

----- Original Message -----
From: "John Dennis" <jdennis at redhat.com>
To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Cc: "Nathan Kinder" <nkinder at redhat.com>
Sent: Thursday, April 14, 2016 9:55:56 PM
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding

I could use some help from your SAML developers because I'm seeing what 
appears to be incorrect behavior.

During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent 
using the HTTP-Redirect binding. The AuthnRequest specifies a 
AssertionConsumerServiceURL for the SP which has the HTTP-POST binding. 
When Keycloak responds with the Assertion in the SAMLResponse it 
incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST 
binding (specified in both the AuthnRequest and the SP metadata). This 
causes a failure because the endpoint for the SP's 
AssertionConsumerServiceURL only expects HTTP-POST, the resulting error 
is an invalid HTTP method failure.

I also noticed that when I used the Web UI to examine the SP metadata 
(Installation tab of the realm client, selecting the "SAML Metadata 
SPSSODescriptor" format) that it did not match the SP metadata that had 
been loaded using the client registration service. Not only wasn't it 
the exact same metadata, but specifically it was missing several of the 
endpoints the SP declared in it's metadata. Why isn't the metadata the 
same and why did Keycloak drop essential endpoint/binding information?

Thanks,

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

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


From bburke at redhat.com  Fri Apr 15 14:16:57 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 15 Apr 2016 14:16:57 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
Message-ID: <57113019.4030805@redhat.com>

Log a jira and we'll implement support for ACSU and ACSI in 2.0

On 4/15/2016 2:07 PM, Pedro Igor Silva wrote:
> Hi John,
>
>      Like we discussed on IRC, KC relies on the ProtocolBinding attribute of an AuthnRequest to decide which response binding to use. We don't support AssertionConsumerServiceURL neither AssertionConsumerServiceIndex. Accordingly with the specs, all those attributes are optional and mutually exclusive. In case ProtocolBinding is not provided, KC chooses on based on how the AutnRequest was sent. Eg.? If sent using POST than use POST to respond.
>
>      Regarding the SP Metadata, I would suggest you to open a JIRA with more details about what you need to get into the SP Metadata and how the mismatch between what you loaded and what is actually published is affecting you.
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "John Dennis" <jdennis at redhat.com>
> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Cc: "Nathan Kinder" <nkinder at redhat.com>
> Sent: Thursday, April 14, 2016 9:55:56 PM
> Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
>
> I could use some help from your SAML developers because I'm seeing what
> appears to be incorrect behavior.
>
> During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent
> using the HTTP-Redirect binding. The AuthnRequest specifies a
> AssertionConsumerServiceURL for the SP which has the HTTP-POST binding.
> When Keycloak responds with the Assertion in the SAMLResponse it
> incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST
> binding (specified in both the AuthnRequest and the SP metadata). This
> causes a failure because the endpoint for the SP's
> AssertionConsumerServiceURL only expects HTTP-POST, the resulting error
> is an invalid HTTP method failure.
>
> I also noticed that when I used the Web UI to examine the SP metadata
> (Installation tab of the realm client, selecting the "SAML Metadata
> SPSSODescriptor" format) that it did not match the SP metadata that had
> been loaded using the client registration service. Not only wasn't it
> the exact same metadata, but specifically it was missing several of the
> endpoints the SP declared in it's metadata. Why isn't the metadata the
> same and why did Keycloak drop essential endpoint/binding information?
>
> Thanks,
>

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


From psilva at redhat.com  Fri Apr 15 14:20:31 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Apr 2016 14:20:31 -0400 (EDT)
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <57113019.4030805@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
	<57113019.4030805@redhat.com>
Message-ID: <129156310.51691951.1460744431323.JavaMail.zimbra@redhat.com>

My bad Bill, ACSURL is already there. I just sent an e-mail rephrasing my statement.

Missing one is ACSI. Let's see if John really need that.

I think he is more concerned about the SP metadata issue that he pointed out.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Friday, April 15, 2016 3:16:57 PM
Subject: Re: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding

Log a jira and we'll implement support for ACSU and ACSI in 2.0

On 4/15/2016 2:07 PM, Pedro Igor Silva wrote:
> Hi John,
>
>      Like we discussed on IRC, KC relies on the ProtocolBinding attribute of an AuthnRequest to decide which response binding to use. We don't support AssertionConsumerServiceURL neither AssertionConsumerServiceIndex. Accordingly with the specs, all those attributes are optional and mutually exclusive. In case ProtocolBinding is not provided, KC chooses on based on how the AutnRequest was sent. Eg.? If sent using POST than use POST to respond.
>
>      Regarding the SP Metadata, I would suggest you to open a JIRA with more details about what you need to get into the SP Metadata and how the mismatch between what you loaded and what is actually published is affecting you.
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "John Dennis" <jdennis at redhat.com>
> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Cc: "Nathan Kinder" <nkinder at redhat.com>
> Sent: Thursday, April 14, 2016 9:55:56 PM
> Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
>
> I could use some help from your SAML developers because I'm seeing what
> appears to be incorrect behavior.
>
> During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent
> using the HTTP-Redirect binding. The AuthnRequest specifies a
> AssertionConsumerServiceURL for the SP which has the HTTP-POST binding.
> When Keycloak responds with the Assertion in the SAMLResponse it
> incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST
> binding (specified in both the AuthnRequest and the SP metadata). This
> causes a failure because the endpoint for the SP's
> AssertionConsumerServiceURL only expects HTTP-POST, the resulting error
> is an invalid HTTP method failure.
>
> I also noticed that when I used the Web UI to examine the SP metadata
> (Installation tab of the realm client, selecting the "SAML Metadata
> SPSSODescriptor" format) that it did not match the SP metadata that had
> been loaded using the client registration service. Not only wasn't it
> the exact same metadata, but specifically it was missing several of the
> endpoints the SP declared in it's metadata. Why isn't the metadata the
> same and why did Keycloak drop essential endpoint/binding information?
>
> Thanks,
>

-- 
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 pkkamos at gmail.com  Thu Apr 14 17:41:26 2016
From: pkkamos at gmail.com (Paa Kojo Konduah Amos)
Date: Thu, 14 Apr 2016 21:41:26 -0000
Subject: [keycloak-dev] Connection Timming out.
Message-ID: <000001d19696$677ed080$367c7180$@gmail.com>

Hello All, I have successfully tested an application using Keycloak
1.9.0.CR1. I have also deployed same on a public IP. It works fine within
the LAN, but once you try to access it from the public the connetion times
out.

 

Please find below the logs;

 

20:43:06,191 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
(default task-2) failed to turn code into token: java.net.ConnectException:
Connection timed out

        at java.net.PlainSocketImpl.socketConnect(Native Method)
[rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
[rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.ja
va:206) [rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
[rt.jar:1.8.0_65]

        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[rt.jar:1.8.0_65]

        at java.net.Socket.connect(Socket.java:589) [rt.jar:1.8.0_65]

        at
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFact
ory.java:117) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(Def
aultClientConnectionOperator.java:177) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
[httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnA
dapter.java:131) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequest
Director.java:611) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDir
ector.java:446) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.
java:863) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:82) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:106) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:57) [httpclient-4.5.1.jar:4.5.1]

        at
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.ja
va:107) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuth
enticator.java:314) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAut
henticator.java:260) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator
.java:112) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuth
enticate(AbstractUndertowKeycloakAuthMech.java:110)
[keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletK
eycloakAuthMech.java:92) [keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(Secur
ityContextImpl.java:283) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(Secur
ityContextImpl.java:300) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(Secur
ityContextImpl.java:270) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(Security
ContextImpl.java:133) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContext
Impl.java:108) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextIm
pl.java:101) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handl
eRequest(ServletAuthenticationCallHandler.java:55)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHa
ndler.java:33) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(
AuthenticationConstraintHandler.java:51)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(A
bstractConfidentialityHandler.java:46)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandle
r.handleRequest(ServletConfidentialityConstraintHandler.java:64)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handl
eRequest(ServletSecurityConstraintHandler.java:56)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(
AuthenticationMechanismsHandler.java:58)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.hand
leRequest(CachedAuthenticatedSessionHandler.java:70)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityI
nitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequ
est(JACCContextIdHandler.java:61)

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(Se
rvletPreAuthActionsHandler.java:69)
[keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Servle
tInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletIn
itialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitial
Handler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletIn
itialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
42) [rt.jar:1.8.0_65]

        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17) [rt.jar:1.8.0_65]

        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]

 

21:00:44,500 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
(default task-5) failed to turn code into token: java.net.ConnectException:
Connection timed out

       at java.net.PlainSocketImpl.socketConnect(Native Method)
[rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
[rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.ja
va:206) [rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
[rt.jar:1.8.0_65]

        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[rt.jar:1.8.0_65]

        at java.net.Socket.connect(Socket.java:589) [rt.jar:1.8.0_65]

        at
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFact
ory.java:117) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(Def
aultClientConnectionOperator.java:177) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
[httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnA
dapter.java:131) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequest
Director.java:611) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDir
ector.java:446) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.
java:863) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:82) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:106) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:57) [httpclient-4.5.1.jar:4.5.1]

        at
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.ja
va:107) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuth
enticator.java:314) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAut
henticator.java:260) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator
.java:112) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuth
enticate(AbstractUndertowKeycloakAuthMech.java:110)
[keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletK
eycloakAuthMech.java:92) [keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(Secur
ityContextImpl.java:283) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(Secur
ityContextImpl.java:300) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(Secur
ityContextImpl.java:270) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(Security
ContextImpl.java:133) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContext
Impl.java:108) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextIm
pl.java:101) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handl
eRequest(ServletAuthenticationCallHandler.java:55)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHa
ndler.java:33) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(
AuthenticationConstraintHandler.java:51)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(A
bstractConfidentialityHandler.java:46)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandle
r.handleRequest(ServletConfidentialityConstraintHandler.java:64)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handl
eRequest(ServletSecurityConstraintHandler.java:56)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(
AuthenticationMechanismsHandler.java:58)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.hand
leRequest(CachedAuthenticatedSessionHandler.java:70)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityI
nitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequ
est(JACCContextIdHandler.java:61)

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(Se
rvletPreAuthActionsHandler.java:69)
[keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Servle
tInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletIn
itialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitial
Handler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletIn
itialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
42) [rt.jar:1.8.0_65]

        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17) [rt.jar:1.8.0_65]

        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]

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

From jdennis at redhat.com  Fri Apr 15 17:51:43 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 15 Apr 2016 17:51:43 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
Message-ID: <5711626F.60300@redhat.com>

On 04/15/2016 02:07 PM, Pedro Igor Silva wrote:

> Like we discussed on IRC, KC relies on the ProtocolBinding attribute
> of an AuthnRequest to decide which response binding to use. We don't
> support AssertionConsumerServiceURL neither
> AssertionConsumerServiceIndex. Accordingly with the specs, all those
> attributes are optional and mutually exclusive.

I don't believe that's true, they are not all mutually exclusive. Here
is my reading of the SAML Core Spec in Section "3.4.1 Element
<AuthnRequest>"

The AssertionConsumerServiceIndex, AssertionConsumerServiceURL and
ProtocolBinding attributes are all optional. The
AssertionConsumerServiceIndex is mutually exclusive with the
AssertionConsumerServiceURL attribute. The ProtocolBinding attribute
may only be composed with the AssertionConsumerServiceURL
attribute. Therefore the ProtocolBinding attribute is also mutually
exclusive with the AssertionConsumerServiceIndex attribute.

Here are the 5 possible legal combinations:

1) None of AssertionConsumerServiceIndex, AssertionConsumerServiceURL
nor ProtocolBinding are supplied.

2) AssertionConsumerServiceIndex is supplied

3) AssertionConsumerServiceURL is supplied

4) AssertionConsumerServiceURL and ProtocolBinding are supplied.

5) ProtocolBinding is supplied.

In the Web SSO case the SAML Profiles Spec in Section
4.1.2 "Profile Overview" in "Step 5. Identity Provider issues <Response>
to Service Provider" the spec is very clear you're supposed to respond
with an AuthnResponse using either POST or Artifact, but *never*
Redirect. Here is the specification text:

"In step 5, the identity provider issues a <Response> message to be
delivered by the user agent to the service provider. Either the HTTP
POST, or HTTP Artifact binding can be used to transfer the message to
the service provider through the user agent. The message may indicate
an error, or will include (at least) an authentication assertion. The
HTTP Redirect binding MUST NOT be used, as the response will typically
exceed the URL length permitted by most user agents."

> In case ProtocolBinding is not provided, KC chooses on based on how
> the AutnRequest was sent. Eg.? If sent using POST than use POST to
> respond.

See above, this is not correct.

You can only respond using either HTTP-Post or Artifact. So which of the
two do you choose? You need to follow the rules outlined above for the
presence of the attributes in the AuthnRequest. Here is how I think you
need to handle the 5 cases enumerated above.

1) Since nothing was specified use a default (HTTP-Post). The spec seems
to be silent on what the default should be but HTTP-Post seems like the
best choice.

2) Verify the AssertionConsumerServiceIndex is valid and specifies a
binding of either HTTP-Post or Artifact, if not it's an error. If the
ProtocolBinding attribute is also specified it's an error.

3) If only the AssertionConsumerServiceURL is specified you have to
figure out if you're going to use HTTP-Post or Artifact. The spec is
silent on how you determine this but a reasonable and friendly thing to
do is scan the AssertionConsumerService endpoints the SP supplied in
it's metadata in order [1] and select the first one which matches either
HTTP-Post or Artifact. If none of them match use the default 
(HTTP-Post). You must verify the AssertionConsumerServiceURL is present 
in the SP metadata.

4) Verify the ProtocolBinding is one of HTTP-Post or Artifact, if not
it's an error. Use the ProtocolBinding attribute for the binding and the 
AssertionConsumerServiceURL as the destination (after validating the URL 
is specified in the SP metadata!)

5) Verify the ProtocolBinding is one of HTTP-Post or Artifact, if not
it's an error. The spec appears to be silent on how to determine the
AssertionConsumerService URL. Probably the best action is something
similar to case 3, scan the ACS endpoints in order [1] and use the first
match.

[1] See Section 2.2.3 "Complex Type IndexedEndpointType" in the SAML
Metadata spec. concerning the isDefault flag and index values. Start
with the default ACS as determined by the rules in Section 2.3.3 and 
then iterate over the remainder of the ACS's. I would suggest iterating 
in index order as opposed to metadata order.

-- 
John

From psilva at redhat.com  Fri Apr 15 18:55:39 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Apr 2016 18:55:39 -0400 (EDT)
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <5711626F.60300@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
	<5711626F.60300@redhat.com>
Message-ID: <1642445971.51753158.1460760939001.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "John Dennis" <jdennis at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>, "Adam Young"
> <ayoung at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Sent: Friday, April 15, 2016 6:51:43 PM
> Subject: Re: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
> 
> On 04/15/2016 02:07 PM, Pedro Igor Silva wrote:
> 
> > Like we discussed on IRC, KC relies on the ProtocolBinding attribute
> > of an AuthnRequest to decide which response binding to use. We don't
> > support AssertionConsumerServiceURL neither
> > AssertionConsumerServiceIndex. Accordingly with the specs, all those
> > attributes are optional and mutually exclusive.
> 
> I don't believe that's true, they are not all mutually exclusive. Here
> is my reading of the SAML Core Spec in Section "3.4.1 Element
> <AuthnRequest>"
> 
> The AssertionConsumerServiceIndex, AssertionConsumerServiceURL and
> ProtocolBinding attributes are all optional. The
> AssertionConsumerServiceIndex is mutually exclusive with the
> AssertionConsumerServiceURL attribute. The ProtocolBinding attribute
> may only be composed with the AssertionConsumerServiceURL
> attribute. Therefore the ProtocolBinding attribute is also mutually
> exclusive with the AssertionConsumerServiceIndex attribute.
> 
> Here are the 5 possible legal combinations:
> 
> 1) None of AssertionConsumerServiceIndex, AssertionConsumerServiceURL
> nor ProtocolBinding are supplied.
> 
> 2) AssertionConsumerServiceIndex is supplied
> 
> 3) AssertionConsumerServiceURL is supplied
> 
> 4) AssertionConsumerServiceURL and ProtocolBinding are supplied.
> 
> 5) ProtocolBinding is supplied.

Right. I've sent another e-mail right after this one fixing what I said.

What I tried to say is that ACSI and ProtocolBinding are mutually exclusive. And usually, ProtocolBinding is used with ACSURL.

> 
> In the Web SSO case the SAML Profiles Spec in Section
> 4.1.2 "Profile Overview" in "Step 5. Identity Provider issues <Response>
> to Service Provider" the spec is very clear you're supposed to respond
> with an AuthnResponse using either POST or Artifact, but *never*
> Redirect. Here is the specification text:
> 
> "In step 5, the identity provider issues a <Response> message to be
> delivered by the user agent to the service provider. Either the HTTP
> POST, or HTTP Artifact binding can be used to transfer the message to
> the service provider through the user agent. The message may indicate
> an error, or will include (at least) an authentication assertion. The
> HTTP Redirect binding MUST NOT be used, as the response will typically
> exceed the URL length permitted by most user agents."
> 
> > In case ProtocolBinding is not provided, KC chooses on based on how
> > the AutnRequest was sent. Eg.? If sent using POST than use POST to
> > respond.
> 
> See above, this is not correct.

This behavior is there for a long time. Since PicketLink SAML ...

I'm pretty sure there was some requirement for that. Probably some odd requirement from our customers. 

And that is why we always recommend POST (and also because the assertion is not exposed) and the usage of that "Force Post Binding". Which is enabled by default ...

> 
> You can only respond using either HTTP-Post or Artifact. So which of the
> two do you choose? You need to follow the rules outlined above for the
> presence of the attributes in the AuthnRequest. Here is how I think you
> need to handle the 5 cases enumerated above.
> 
> 1) Since nothing was specified use a default (HTTP-Post). The spec seems
> to be silent on what the default should be but HTTP-Post seems like the
> best choice.

See above. We do that. And, AFAIK, we don't support Artifact.

> 
> 2) Verify the AssertionConsumerServiceIndex is valid and specifies a
> binding of either HTTP-Post or Artifact, if not it's an error. If the
> ProtocolBinding attribute is also specified it's an error.

Do you really need ACSI ?

> 
> 3) If only the AssertionConsumerServiceURL is specified you have to
> figure out if you're going to use HTTP-Post or Artifact. The spec is
> silent on how you determine this but a reasonable and friendly thing to
> do is scan the AssertionConsumerService endpoints the SP supplied in
> it's metadata in order [1] and select the first one which matches either
> HTTP-Post or Artifact. If none of them match use the default
> (HTTP-Post). You must verify the AssertionConsumerServiceURL is present
> in the SP metadata.

Considering that we don't support Artifact. We would always choose POST.

Do you need Artifact ?

> 
> 4) Verify the ProtocolBinding is one of HTTP-Post or Artifact, if not
> it's an error. Use the ProtocolBinding attribute for the binding and the
> AssertionConsumerServiceURL as the destination (after validating the URL
> is specified in the SP metadata!)

That is fine. But again, no Artifact.

The ACSURL is always checked against the valid URLs you specified in your client configuration.

> 
> 5) Verify the ProtocolBinding is one of HTTP-Post or Artifact, if not
> it's an error. The spec appears to be silent on how to determine the
> AssertionConsumerService URL. Probably the best action is something
> similar to case 3, scan the ACS endpoints in order [1] and use the first
> match.

We already choose the ACSURL based on the client configuration.

> 
> [1] See Section 2.2.3 "Complex Type IndexedEndpointType" in the SAML
> Metadata spec. concerning the isDefault flag and index values. Start
> with the default ACS as determined by the rules in Section 2.3.3 and
> then iterate over the remainder of the ACS's. I would suggest iterating
> in index order as opposed to metadata order.

Do you need that ?

I think the point is, can you live with ProtocolBinding and ACSURL ? Or do you really need full spec support (ACSI, etc) at this regard ?

Beside that, please note that if you don't provide a ACSURL, KC will choose one for you accordingly with your client configuration.

> 
> --
> John
> 


From ayoung at redhat.com  Fri Apr 15 22:07:34 2016
From: ayoung at redhat.com (Adam Young)
Date: Fri, 15 Apr 2016 22:07:34 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <57103C1C.8060806@redhat.com>
References: <57103C1C.8060806@redhat.com>
Message-ID: <57119E66.6040005@redhat.com>

On 04/14/2016 08:55 PM, John Dennis wrote:
> I could use some help from your SAML developers because I'm seeing 
> what appears to be incorrect behavior.
>
> During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent 
> using the HTTP-Redirect binding. The AuthnRequest specifies a 
> AssertionConsumerServiceURL for the SP which has the HTTP-POST 
> binding. When Keycloak responds with the Assertion in the SAMLResponse 
> it incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST 
> binding (specified in both the AuthnRequest and the SP metadata). This 
> causes a failure because the endpoint for the SP's 
> AssertionConsumerServiceURL only expects HTTP-POST, the resulting 
> error is an invalid HTTP method failure.
>
> I also noticed that when I used the Web UI to examine the SP metadata 
> (Installation tab of the realm client, selecting the "SAML Metadata 
> SPSSODescriptor" format) that it did not match the SP metadata that 
> had been loaded using the client registration service. Not only wasn't 
> it the exact same metadata, but specifically it was missing several of 
> the endpoints the SP declared in it's metadata. Why isn't the metadata 
> the same and why did Keycloak drop essential endpoint/binding 
> information?
>
> Thanks,
>
Was that 1.9.0 or 1.9.2?  I thought they said that there were some bugs 
in 1.9.0 that had been fixed in 1.9.2.  Looks like they dropped 1.9.2 
final later on today.

From jdennis at redhat.com  Fri Apr 15 23:58:33 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 15 Apr 2016 23:58:33 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <1642445971.51753158.1460760939001.JavaMail.zimbra@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
	<5711626F.60300@redhat.com>
	<1642445971.51753158.1460760939001.JavaMail.zimbra@redhat.com>
Message-ID: <5711B869.4030004@redhat.com>

On 04/15/2016 06:55 PM, Pedro Igor Silva wrote:
> What I tried to say is that ACSI and ProtocolBinding are mutually
> exclusive. And usually, ProtocolBinding is used with ACSURL.

> And that is why we always recommend POST (and also because the
> assertion is not exposed) and the usage of that "Force Post Binding".
> Which is enabled by default ...

>> 1) Since nothing was specified use a default (HTTP-Post). The spec
>> seems to be silent on what the default should be but HTTP-Post
>> seems like the best choice.
>
> See above. We do that. And, AFAIK, we don't support Artifact.

> Considering that we don't support Artifact. We would always choose
> POST.


> The ACSURL is always checked against the valid URLs you specified in
> your client configuration.

> We already choose the ACSURL based on the client configuration.

> I think the point is, can you live with ProtocolBinding and ACSURL ?
> Or do you really need full spec support (ACSI, etc) at this regard ?

It's not a question if I can live with ProtcolBinding and ACSURL, I have 
no control over what an SP sends. If a SP sends only an ACSURL Keycloak 
needs to perform a POST with the AuthnResponse. You've said multiple 
times above that Keycloak will do a POST with the AuthnResponse but 
that's not what Keycloak is doing, instead it's causing a GET on the 
ACSURL using the HTTP-Redirect binding. So we need to figure out why 
Keycloak is not behaving as you believe it should be.

I've attached the protocol exchange with annotations as a text file (so 
the mailer won't mangle it). Maybe I've stared at this too long and can 
no longer see what's in front of me (a good chance) but it sure looks to 
me like Keycloak is behaving differently than expected.

Many thanks in advance for your help Pedro!

-- 
John
-------------- next part --------------
The SP is "jdennis_test.example.com"

The IdP is "ipa.jdennis.oslab.test:8180"

The Keycloak realm is "jrd"

The SP metadata has these AssertionConsumerService definitions:

<AssertionConsumerService
  index="0"
  isDefault="true"
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  Location="https://jdennis_test.example.com/mellon/postResponse" />
<AssertionConsumerService
  index="1"
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
  Location="https://jdennis_test.example.com/mellon/artifactResponse" />
<AssertionConsumerService
  index="2"
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"
  Location="https://jdennis_test.example.com/mellon/paosResponse" />

These are the sequence of operations and protocol content as recorded by SAMLTracer (headers and cookies omitted for brevity).

1) SP Sends AuthnRequest (HTTP-Redirect) using GET Method to Keycloak IdP

"http://ipa.jdennis.oslab.test:8180/auth/realms/jrd/protocol/saml?SAMLRequest=jZJPT%2BMwEMW%2FSuR746Rk2dRqK5VkI1ViESqwBy7IpIMw8p%2BsZ8LCt2ecAmIvwMnSeJ7f%2Bz15idrZQW1Guvc7%2BDsCUvbkrEc1XazEGL0KGg0qrx2gol5dbH6fqnleqCEGCn2w4oPkc4VGhEgmeJFt25W4OVnUm7I%2BqhZdVdZdWTddM5837a%2B2btui%2B7kQ2R%2BIyPsrwXIWIY6w9UjaE4%2BK8nhWVLOyuixrVc3Vj%2BNrkbXMYLymSXVPNCgpzaDzhz14bzAPaPVtTryl6rIupGZ2GUFbh%2FIh7uUblUw4ImuCR0hun3H1hyXVjzHyOTNusKY3JLIuxB6melfiTluEBHHOPZhHeJ9s3mpJZqODeAHx0fRwtTs9ICAzvOa%2FSclzeNJsAXkfnHRgbfByCEg7wCFFEetlSq%2BmvuL6u084IL3XpJfyo3p5%2BCNnTL1tzwODPScsp78oJU3MfnY3rSqK2qPhchiXzf41XDlxBRRHEHJ9sPz%2FJ65fAA%3D%3D&RelayState=https%3A%2F%2Fjdennis_test.example.com%2Fprotected.html&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=e0igBOxNYr6Lu4nVUoyhfhD4zznUMjhiULqk4DpLG16puOJsbam%2FJ1vtxGF1rTki%2FZEztLnciFHCEfgNx4RkPY7gFxOGsfol9PirZ7lcrSqNalt3rFA8eAAVnX%2F3TeuZPtKBqSCkUFl8%2FSKj%2FIkxbWNw0WrBV2HnBG%2BAnjWVyTlI0UHNR5LXiBxo1MRyP04Z6TdPvKbmVUxgi163yIli96nFMb1E5uBqEsjwEHE5ucZKIMRuxevPEaf7D3ODpH0jH13AlgHYvNIWU%2BN%2FTVOO75%2FvzMytrpwQh6j49fyhy0CMLW6Jmlgopo7%2Fmca6iIYp0dNjKGCpd0DfR4joRKHBZA%3D%3D"

Decoding the above HTTP-Redirect yields this:

"<samlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"_B98A18349F418F18CFC22CDED8DD0F79\" Version=\"2.0\" IssueInstant=\"2016-04-14T18:42:56Z\" Destination=\"http://ipa.jdennis.oslab.test:8180/auth/realms/jrd/protocol/saml\" Consent=\"urn:oasis:names:tc:SAML:2.0:consent:current-implicit\" ForceAuthn=\"false\" IsPassive=\"false\" AssertionConsumerServiceURL=\"https://jdennis_test.example.com/mellon/postResponse\"><saml:Issuer>https://jdennis_test.example.com/mellon/metadata</saml:Issuer><samlp:NameIDPolicy Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:transient\" AllowCreate=\"true\"/></samlp:AuthnRequest>",

2) Keycloak IdP Authenticates User

[IdP authentication protocol omitted for brevity]

3) Keycloak IdP responds with a 302 redirect with this location header
causing a GET operation on the SP ACSURL (which is only expecting a
POST). Note, "https://jdennis_test.example.com/mellon/postResponse" is
the default ACS in the SP metadata with a HTTP-POST binding. Note also
this is the AssertionConsumerServiceURL in the above AuthnRequest.

This is an HTTP-Redirect binding using GET. This is *not* an HTTP-Post.

"https://jdennis_test.example.com/mellon/postResponse?SAMLResponse=rVjXruRGkv2Vxp1HopveXagF0HtW0RXNi8Ci954s8uu3uiVhRrs7A2GxjxkZJzJOnGAGyV%2BWuGvHTztbxqFfsi%2Bvru2Xz5%2FG7x%2Fb3H8O8VItn33cZcvnmnw6jKF%2FIt%2Bgz3Ee1iEZ2o9%2FgfxnRLws2bxWQ%2F%2Fxhc%2BWterjH4vvH%2BW6jssnCNZp1vfV8tv63vyWveJubLNvydCBXda2Qw%2BOw7L%2BmefHF4X%2F%2FqHwvyUwRcUYmX5FiSz9ilE0%2FJVCaOorkqcQDWV0%2BqTgt3P%2FJ9Advn%2F8xtIUA1MoRosYTIkwxYkcgnC8wFM8D4kk%2FQYsy5Yp%2FbLG%2Ffr9A4Fg4iuEfYUxF6Y%2BMfQTwb7BMBF9fHlk8%2FKTxJvgx6%2B%2F%2FCjC50%2Fs%2FOsPWm9W1Rh%2F%2B4PZt2Fp4%2Be3H%2Fw%2BKZiCwHhbS3DO4rZbwHpOfwH%2FFf%2FL78o4a7xuy19X3JBmXx5xu2X%2FueLLT%2B9PZ0uSbFk%2BwF9%2FP%2BGvQT%2BFPpnPcc1S5k%2BBfv3llfXJPzf4eI3%2FkPnHxu%2BSvbkdx%2FHtQL8NcwEiEASDEAa%2Bvd4e%2F%2Fj44p5j9jcchTbrsn79%2BOuR7xyMbC2H9AvTFsNcrWX3N2LF2QIj1Nfkmfygmi6fWnYqfT78kXq6%2FJsYEAjRP2KkS1X84%2BO%2Fk38H%2Bf9Ibl7ir%2FBv%2BI%2FMfgbjqrHM5h%2BV%2FYvhp6q%2Fjrp1X1bANtcHbcdR0PtbpD0p3lDB0IuZerQLpRS0oLQi68aUHRLgOOjhNzfVpevKyEnMzGNOW%2FN5dmHNnmRObffXvhdgJdkZO1F0SecRYcNCAluqiA6vYPJfV1B4TguYW183p5ILlK3fIid9Dox8ydJEJ1v%2BAhc7hLokNti7g7l8IRuPTbFidwtkaknA%2FVlqUKIsFkgnvPbwyFBbYvCVeQxhHRok2qI%2Brx2d1g5r4CtiYhuYStg2ODyqpuJTNTWjgEOV031RAYSTzgiU42a77Po6LOsx9%2Bu6oBVDB1YJew1%2BzV01TLfZgvrFKuzoxlPIqp%2FoVbfmwC5sJLA6fUJGMDJexnz%2F%2Fgv4P0r9F9PvcoD%2FSwOA%2F2ynvyMgp4oy0y3JBCTUpkKlle3tQsLp1W2WQwWDs78mlHyKGzWzRnYpsChYYEluMvNg%2BQLERgtGmKTKb%2Bjjug6gd2heTIo4jtbqGQMUA3kWLsiWIANQXgmbtqkWjdxL0qsTNRpxXH8UHcKMTxMDnvNN42lR2eVRW%2FlV1ZxQfV%2BnPh%2BWb13jPivIsif86ZJS3kWU53AgDZ8baZtJKn5vnmg3BeBuj71hp9mtVR%2BlL0O5AL4FhcNdt3ul1nLPoLhhk5VWK%2FIHiWM9zmgrY0q%2BKTBkhVM0BhJBczef3ZZVg2TnwCoAvWU%2BKhDCHeW8pavuYetOIU4OAwMb5eKAT2LTYOBC2BcwUOveIa5j4SVsJQIG3SMgyYPlIeAE5c1ajlgBBML87LIBiUURS5mxz0%2FxInBWnbs3%2F1ZiL5nnJP2iK6qOBexBnDcuKHOBdDUx4PKop3qe9SREGgHw3cwsw7bw03pm7RNLMf6e0KKQBXVr9xmFRNN%2BH5hA0jppFDAtLIuV05V%2Bm63pCC7iiEZPYzqBAxXvJtd2qHCXMrE45DeYTHU%2BwzFbEfpQcsS0OGBM415iZS%2BZpdGZyENRJydnjMqpY%2BPzED14RzE2L5%2FyVqVfecjOAHYRHiHQtRXcDUNXLNaFsvxO1B0ws4nTuNqZIHqZu3hTEOsmJt54lCqen%2FfSZUzQXxWZfKSZy%2BQHaCLc86JSIfUT5gaZ%2BRwqZ9%2B2%2BRjrnjBUM9FsQgi76lQFgDQ%2BR5qM32Mwu7ykS4AbquG7ugvKDTwB4g5GPrN0rMrX92llOHgHskAYiqUf1MRrsYlp2lavItJCjzBw8aE4BgQ65Aplp43F6IgB62uQMSO0CPJi1xKN0rJzRXro4%2Fkt9IvYObVPhMGUoLNcbUAy4OcEnKnmCHhKKlvQ5RmHiDA%2BdxAODJJndEP55DAk6LtSIJB7lz46t9569EVUw4qBwpG7fddMD01l8aFvri42%2BYE3HzLTyrz%2BssSQLSshD4G1iGJqsA63pCsn81hJASQcXBK85YNNVEImI804fUQoetvyRO24w2xYWk0sH4%2BNmWkxh%2BHnVzMWp9wBjm3pr8hvFkLTZljf2XnlqHgMMAmrVlZik5ACu1iUO%2FblGmoFssBAEqGatAmuzw6FH2d3I8mOiC7zeZP6HPBqGohzr5bOh%2BnRreHSm2LvF1YZVieogHaT7RXcIxA1n%2B2aBwGlaVgsgKRJoJCcLYolCUzSEaNXBgkaQQ%2FBYO6oIJNjyDIvVSWdHeUBUhfctAoHh0OBAdZoXbDuT9tAmknIC92%2F41Xmn%2BDkPEHyAK901u0QZ1aT4Sf3Jvk6xbkQbd1lk%2Btn1F1S9mbaUQ5ORx226Zn5MINuzMnMriG7FfZY3nXW17ErkO7ZjU%2FhTZO1xxYogsoLTUurXc5MeHEc16RaLbzd2VXZy5bJwvLQFJtdIiqSdhDoaaOVUitNLuAWRpFojibR3WdRt2ofbairmaxHL8tsJr9HpZc%2FVgRFxfX0GLhSr%2BwC3yMo9GH9wco7w4ZaIDkAKGK392UWRnZn2dtRN7zm9sqFeLR9NIWt5adsPmsei%2FtwmzHaZBJx97d1Ax95rx9QdNt4qe6sXmy1s06sCrXeE%2BsqgX112yDEXqEQPSJHxSEoWKwnzA6J%2F1BwU2UXnfO8PNFOZEFN9cLB%2BxzeYSLu6BOV2q6A0kh44OwhFLwKe9DjgRHEyFFO6%2BtoZ3HDvgOOaHOJDuC37DB1RSfDZJldxrmHQNvPk1IeUavUqUPy3bMYG9RmHeiaqFsAtRPRcKgJ%2BZafIq3gyqPer0d%2Fz2DpcdPc%2BvBtonhoONhfrzOq6lRDjwnX4WPczsiVdodvozJTQvbM6GRfTv4pZlNalEcTJps0PcD5hmItgcYd5heM5KaXGVdbGGUjbhXPwYB27GItQ%2BMBRrFUs5nyjRsW4gUcAoteU%2BHOLyoklK4FM2sSEUXmz0IJ4YY6yysAFQApK1S5qg4DKXC7jTvuFZweaxAJCAhTDXMsukVUpbkqHsnIAtmM5y0RYaKbGbGP46qxgU8yCxFZebHV2RNLZ1MPLD4LOjTbsQcBzjjvHQhjcNPDRSCZTSm9kjS8ErqNDyUnD9xCXhFwvzUbNnJ%2BJfANNdswSwdTjEl7xAgSOU6KhGaZIfZ6Mi0YxL%2BenpDfYyVJrqy9E6czmREFqRyJEo3LO%2FO60tJNptT0WRsXgO2XLretzbQbsO%2B8R7uH1AdB1%2FP6yGEwYvWvlIlkPAtwqgEXL5ooVQ5l2GpSgXNvoZC%2FlKQu2ltYiMucqoiK3PpZwScZO%2BetFRQ5UQMMGamCsi9xVTroJUv1GNpMpGPmaizsxNqS3YxOHzUzPdGhcwsec2Hfc0E6yNH0NsS9JS3NukJbpBIcS0U8cObK9duZMj6okdwwgCCinymvkLTEkvtGPC5473vhfcGcPLFPeYQRvaYUs3VEPOhbkSNFxUhIae9IekOQvDqxiug%2BM4nfMXKlKMLues0FqtCb5BoOzwXDlXILixcziOBLr3C58GCltqOVlnc%2Fmc0XFDnoRY6DXgeLg%2Bz%2BaNz3rWpSj2hDCUVq7o2RdRwjVucVsreB4u8poQ66sbn%2BPX%2B6zhUgiPGg6Kl7phTD2Y9XqxfKzEDNYhVeGnv8NYckGzEdpNIy6%2BumtlFYoZFiZRj0%2FcWvzs5LGlSw0IjZ6R53W5vR2EmLGsElrqFA7P3yPPH9RAzQew4Ron8DzeLqDT2dguOCbWpuDGOYFZMY8B4OlorVrMmIGRTNy%2BjxbIlTh52tj%2Ffm%2F%2FZS%2FIfx335Agn%2F9r%2FDrfwE%3D&RelayState=https%3A%2F%2Fjdennis_test.example.com%2Fprotected.html&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=LMExafl6qj8rm13lPnprTYzYlMcurgFcYDOS57av7BULmYByJZnggTn0lrKeBgfctheDv53jtJnGweyVoAiT9LpQvv9w80gYYVKA103e%2FQbhpL%2F9%2B5FbGMGBxe%2Fei6w1fqAujcGqidSVjecszeCtkrIXbbPLI7ZMgciUAH01A0S0nqOKxZc%2FF8RDTVLSqiytGiPXV2e96RKfMq%2FHCC%2FGZI%2BqNj1kE5WefreMY3IMPYAwRrhyZDTo%2FG5yzI5BMCx%2Fn78ljRah9AWlxK6BHcxW8y5pgCdJORwC4H8PQdpKVkMF6GSox6U2evA1Rhzyrv6dYTm0KBQY7MnyW4gIhK1EnA%3D%3D"

Decoding the above HTTP-Redirect yields this:

<samlp:Response xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" Destination=\"https://jdennis_test.example.com/mellon/postResponse\" ID=\"ID_c188a47d-36ed-4891-8298-2fd090e9db81\" InResponseTo=\"_B98A18349F418F18CFC22CDED8DD0F79\" IssueInstant=\"2016-04-14T18:43:24.116Z\" Version=\"2.0\"><saml:Issuer>http://ipa.jdennis.oslab.test:8180/auth/realms/jrd</saml:Issuer><samlp:Status><samlp:StatusCode Value=\"urn:oasis:names:tc:SAML:2.0:status:Success\"/></samlp:Status><saml:EncryptedAssertion><xenc:EncryptedData xmlns:xenc=\"http://www.w3.org/2001/04/xmlenc#\" Type=\"http://www.w3.org/2001/04/xmlenc#Element\"><xenc:EncryptionMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#aes128-cbc\"/><ds:KeyInfo xmlns:ds=\"http://www.w3.org/2000/09/xmldsig#\"><xenc:EncryptedKey><xenc:EncryptionMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#rsa-1_5\"/><xenc:CipherData><xenc:CipherValue>pLQPst+RNtV9RaZXnWuZKb8DMJ/YUaAjpRgIhEKXhQZQOAhm2X55/U5OTdLGzze7qFeNwrdlNbymYjBy7f8uPxvvg/iGReBq89h9fZ6R1Ec1QJF3oxXqWxzXgUSl+NunjkyIfE8RLOZSdboAHzHGq9cufx/sRY0mcaMBPS4TDgHMVuIQaTuXH8sc/vbhK0cIsQ/9cDKVU7YKsa/xeUA6QwK0FRFLrtm9djSBM5t2N4u/dG4uoSD3JdFbJNKMg1YJCLWFI+Ey9e63CCrRhmnjYhjpfWjjg9IML+tG4xoWjCzj19les3WgtEv3uD82tLy3zjlNoBsBZEBL9y0MXpAUeA==</xenc:CipherValue></xenc:CipherData></xenc:EncryptedKey></ds:KeyInfo><xenc:CipherData><xenc:CipherValue>CJFHAmscq+c8uJ0hQevls71dzmuQS8XoSvxq37bFu8rBMezI1FEQ/h7uHAVBDg/4pQ12AcifO3Vzzw+nS9DFcgaaZtiba+8A0UQ5EHQEH+0fiEuKuJQ92Ph7UjcJZp55LVgm2ApbN4+brOKD9FIvHpKtDtJKSYJlonWDYhAHzaneg7hn6WqzGdDT2Ibow2kDfMdleGJ5Pkb3mqX/vRpnMRdeOlJVhWH0fE/6Qw1YvLRnIjKfUM8CouHIlKgfV754n5AKtANGWNEA7i5894/6XkPNbmueioGRf+tE+nQNVi/05SIyOdtLU4tv82Sf1+oBZfFo5qFkk4/s6Rz+o8tvm2TSQ5h1QcE40PZ+cfXsVE568UrKf2QX0/1DrTBX74ZZB8NaWDqasECQjfTOWOh4xHDCGLz9i8jaE4V6yOCXhfE7TKFXCfZn8nDBUG2Gp+/XH8BABl1bQbelb4d4DPc9FEeXjlRne82ZqvPoAXGKmGpE4KYhgtCLInurQqwXz6wZpUKAmEC/IUOHjRYICzIqB50Wk4H8mWACAugYW0cwa9Fo4AkTzFiRseQK9eFD0ZmHcya3HdSR5roZVDSIMuUfqflJ9xfYBr+4z6U6E9jQXPMMLIQBT0efP6jm+rBcSkTKyc2LhfT5kg6tuFcUpwhJ5fyPhTAN/WtIH7VdeTAfw/N2Cbz8dEdWcAO0NfrYIynllfpaLUEoir6kuEY1TJqiX+Gpbp97a14TezUcmc+O3K5vJvEIO/y+6P/ZWAsmBJDjPqtAC1v+eXEogsnoJcUl4qAkllLiZ7Q3wYXT5ogwo20wHi3BquB49ZA/jzoH4MYQ67zBth3ZdhmTF9onarE56x6vCJncEoNG0yhtR+GM1bq+ydKSE5d7IuXmfeC2F15rm05+oGUMmohbC42XnmhE62PmdVmTjun3x6iot4/EwfTnmkqVKJB5onkzmaNDoDNVHAlHDLxQFYBhiEfY+tgZa8oQwTh9iSeUBGI+G5/sc5lDXuFIYAe7NadVZ33OufcJmCwNkB9JcQW5aMrAl4SADrxkpgyHm+SRQLxZWks6KKr1LvBrtC8apX4G4itBGBcY8/maFHmBxTMJi/B+o76YJclc5LrS85wymO77m6ZzNbOGnf+Uj9+afUjGyVNU9lMT9uIRvz4iMQmEJ+KOHRt/vZ/3NbltfXX8KK4aE/7N630HesIQGEAcm6pUhXc3Z0VEMAP3EH7pYBAxJJ7Sv3D+7LETdiYoSC3+o1K9LEQPbRM2kqEfgLWP5ieWy/qSb/7w/zdrLRY5AtNADqTOGWL8CT09QPHNCnr3TsdBONRZf/qwjYldyeW1A3uAyArTMHTi4Vs9iSLtpmg2mbmpbEGnfBRpl+gXiUYNQKjTCNcDFpptcitQ5lvBtIvhlAeYhwKIRBsZ8ZGv/+n9MlGdQdcz+OYZZFNpN6mPrFLQjW3k8zkqQVnHHBeHymYUfVt233FtyUA1iJzez/9e6YW1LVBHvABYKXGS+/F4OXkPYZRmQRuwjkDKTnIz2U9RwkgRKfyHNbjD4anYur49NAcFvWutu/VfnLw0ZOuDGjmQnFlKyjcQi3Qy3zzh+vtTlXY4xYEZVZSJ500XsQb1BocWVI5NJBsLCUUfcKy2s3NJz5/PrYP16am9y3Glmg0dZEV5BwEgDJ1U0VV466pC8SlWL3mQCovv+SFRCcL+5OewNLIL7YcsrTASPY+lnrqIhwZlIjdS7Dmbgpk3RBS0zq8OX0lq6kC3N0WQWd2lETHpLntwnPe1GVOKTjwWR6gVK5/nzxyZijdK3wq5L1wpuyZTGvSDlZheIYBye9cvsyDbFeqdghwkYcuGqV/rO34l63am4WgAGTdzNaiuYZep5QgboM0v4zBQMKD+AIQJNkqfuCos6x+wEB3zqgTrx8Y6Iml/eQqF2IHDygIY1k8yhzX/I+2hi3Izim4/8/uOpv5UgCLaK07+E2AioraFTgZidfJFwcpB+er5fl6Z4FTeMaW55JMu/b7eY2HIxBiyn6smR8V4ayg9YNlpn/+CMyPm/141kn1gXGNkhGxcdYzc9lawIf7w5Q2xZ+POku4pCWiEDk8rR1B9Xqa4GvZAEG7pqIG3eeMFnLcqs40DxbUEfPaIcczelP6ySqNZ80JC736kTDSrtt9GOH8JdbjMz+4vzLHllRAlu+vvDU9TwGnXXmnDLpC412QnxdAZH5eX58k/sUZq8JHYH1QkdECTOYEfxIcjglOYgFsrdJ2J2OnrI5qH4yrulEIHcJX42p8g8RzFtIm0xHGjpYRAZL4NtMsBqBRGRkpSnZkr9q9YSOXVrgRPfEGw7pNUu2TOcl9BTElgdG1aGgaoCNtCnuydAW/K7Coo//2LydDI79GB7vu6Vz1vnnEWP5yD6vqfZ46nKIgrQwZD/WQZSGZgp6GdnSGLk67DJqBIFTbeGDv47t886RmnKT+iYUqHj1Yys45IhuYgxAoF/xLi5HgU1IjRZt9HvWcrNx0ZS3z7poLjXsS2vWpMPvuikdU6lYG32jCi5HHL546tSxYBOo8DPd6JoLMuTWPfbTSzX22MV89qmbd8ACRVxlLgIrA0ksQgUdaUDzrY7BZAm0J9HBWLNKu84gK7FiMM9PxDtSvDGK0gB0p4Rdvamule94y9FK6CcTMI0BPzUUFzBQo0G5/6FWO/NgznMLdqXwz1R8rkMMorIN6o5n1XsiBKQqMaA33fhZVbl6yL1Sunavk=</xenc:CipherValue></xenc:CipherData></xenc:EncryptedData></saml:EncryptedAssertion></samlp:Response>"

From pkkamos at gmail.com  Fri Apr 15 10:01:31 2016
From: pkkamos at gmail.com (Paa Kojo Konduah Amos)
Date: Fri, 15 Apr 2016 14:01:31 -0000
Subject: [keycloak-dev] Accessing Application from public IP
Message-ID: <004501d1971f$534f6eb0$f9ee4c10$@gmail.com>

Hello All, I have successfully tested an application using Keycloak
1.9.0.CR1. I have also deployed same on a public IP. It works fine within
the LAN, but once you try to access it from the public the connetion times
out.

 

Please find below the logs;

 

20:43:06,191 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
(default task-2) failed to turn code into token: java.net.ConnectException:
Connection timed out

        at java.net.PlainSocketImpl.socketConnect(Native Method)
[rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
[rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.ja
va:206) [rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
[rt.jar:1.8.0_65]

        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[rt.jar:1.8.0_65]

        at java.net.Socket.connect(Socket.java:589) [rt.jar:1.8.0_65]

        at
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFact
ory.java:117) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(Def
aultClientConnectionOperator.java:177) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
[httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnA
dapter.java:131) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequest
Director.java:611) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDir
ector.java:446) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.
java:863) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:82) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:106) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:57) [httpclient-4.5.1.jar:4.5.1]

        at
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.ja
va:107) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuth
enticator.java:314) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAut
henticator.java:260) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator
.java:112) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuth
enticate(AbstractUndertowKeycloakAuthMech.java:110)
[keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletK
eycloakAuthMech.java:92) [keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(Secur
ityContextImpl.java:283) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(Secur
ityContextImpl.java:300) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(Secur
ityContextImpl.java:270) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(Security
ContextImpl.java:133) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContext
Impl.java:108) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextIm
pl.java:101) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handl
eRequest(ServletAuthenticationCallHandler.java:55)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHa
ndler.java:33) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(
AuthenticationConstraintHandler.java:51)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(A
bstractConfidentialityHandler.java:46)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandle
r.handleRequest(ServletConfidentialityConstraintHandler.java:64)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handl
eRequest(ServletSecurityConstraintHandler.java:56)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(
AuthenticationMechanismsHandler.java:58)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.hand
leRequest(CachedAuthenticatedSessionHandler.java:70)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityI
nitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequ
est(JACCContextIdHandler.java:61)

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(Se
rvletPreAuthActionsHandler.java:69)
[keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Servle
tInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletIn
itialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitial
Handler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletIn
itialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
42) [rt.jar:1.8.0_65]

        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17) [rt.jar:1.8.0_65]

        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]

 

21:00:44,500 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
(default task-5) failed to turn code into token: java.net.ConnectException:
Connection timed out

       at java.net.PlainSocketImpl.socketConnect(Native Method)
[rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
[rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.ja
va:206) [rt.jar:1.8.0_65]

        at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
[rt.jar:1.8.0_65]

        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[rt.jar:1.8.0_65]

        at java.net.Socket.connect(Socket.java:589) [rt.jar:1.8.0_65]

        at
org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFact
ory.java:117) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(Def
aultClientConnectionOperator.java:177) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
[httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnA
dapter.java:131) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequest
Director.java:611) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDir
ector.java:446) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.
java:863) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:82) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:106) [httpclient-4.5.1.jar:4.5.1]

        at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.
java:57) [httpclient-4.5.1.jar:4.5.1]

        at
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.ja
va:107) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuth
enticator.java:314) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAut
henticator.java:260) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator
.java:112) [keycloak-adapter-core-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuth
enticate(AbstractUndertowKeycloakAuthMech.java:110)
[keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletK
eycloakAuthMech.java:92) [keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(Secur
ityContextImpl.java:283) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(Secur
ityContextImpl.java:300) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(Secur
ityContextImpl.java:270) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(Security
ContextImpl.java:133) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContext
Impl.java:108) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextIm
pl.java:101) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handl
eRequest(ServletAuthenticationCallHandler.java:55)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHa
ndler.java:33) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(
AuthenticationConstraintHandler.java:51)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(A
bstractConfidentialityHandler.java:46)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandle
r.handleRequest(ServletConfidentialityConstraintHandler.java:64)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handl
eRequest(ServletSecurityConstraintHandler.java:56)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(
AuthenticationMechanismsHandler.java:58)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.hand
leRequest(CachedAuthenticatedSessionHandler.java:70)
[undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityI
nitialHandler.java:76) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequ
est(JACCContextIdHandler.java:61)

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(Se
rvletPreAuthActionsHandler.java:69)
[keycloak-undertow-adapter-1.9.0.CR1.jar:1.9.0.CR1]

        at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.
java:43) [undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Servle
tInitialHandler.java:261) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletIn
itialHandler.java:248) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitial
Handler.java:77) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletIn
itialHandler.java:167) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:761)
[undertow-core-1.1.8.Final.jar:1.1.8.Final]

        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
42) [rt.jar:1.8.0_65]

        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17) [rt.jar:1.8.0_65]

        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]

 

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

From bburke at redhat.com  Sat Apr 16 10:01:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 16 Apr 2016 10:01:08 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <5711B869.4030004@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
	<5711626F.60300@redhat.com>
	<1642445971.51753158.1460760939001.JavaMail.zimbra@redhat.com>
	<5711B869.4030004@redhat.com>
Message-ID: <571245A4.2090501@redhat.com>



On 4/15/2016 11:58 PM, John Dennis wrote:
> On 04/15/2016 06:55 PM, Pedro Igor Silva wrote:
>> What I tried to say is that ACSI and ProtocolBinding are mutually
>> exclusive. And usually, ProtocolBinding is used with ACSURL.
>
>> And that is why we always recommend POST (and also because the
>> assertion is not exposed) and the usage of that "Force Post Binding".
>> Which is enabled by default ...
>
>>> 1) Since nothing was specified use a default (HTTP-Post). The spec
>>> seems to be silent on what the default should be but HTTP-Post
>>> seems like the best choice.
>>
>> See above. We do that. And, AFAIK, we don't support Artifact.
>
>> Considering that we don't support Artifact. We would always choose
>> POST.
>
>
>> The ACSURL is always checked against the valid URLs you specified in
>> your client configuration.
>
>> We already choose the ACSURL based on the client configuration.
>
>> I think the point is, can you live with ProtocolBinding and ACSURL ?
>> Or do you really need full spec support (ACSI, etc) at this regard ?
>
> It's not a question if I can live with ProtcolBinding and ACSURL, I 
> have no control over what an SP sends. If a SP sends only an ACSURL 
> Keycloak needs to perform a POST with the AuthnResponse. You've said 
> multiple times above that Keycloak will do a POST with the 
> AuthnResponse but that's not what Keycloak is doing, instead it's 
> causing a GET on the ACSURL using the HTTP-Redirect binding. So we 
> need to figure out why Keycloak is not behaving as you believe it 
> should be.
>

You can configure keycloak to always send a POST.  That is the 
workaround right now.

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


From bburke at redhat.com  Sat Apr 16 10:04:03 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 16 Apr 2016 10:04:03 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <57119E66.6040005@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
Message-ID: <57124653.9090803@redhat.com>



On 4/15/2016 10:07 PM, Adam Young wrote:
> On 04/14/2016 08:55 PM, John Dennis wrote:
>> I could use some help from your SAML developers because I'm seeing
>> what appears to be incorrect behavior.
>>
>> During testing with keycloak-1.9.0.Final a SAML AuthnRequest is sent
>> using the HTTP-Redirect binding. The AuthnRequest specifies a
>> AssertionConsumerServiceURL for the SP which has the HTTP-POST
>> binding. When Keycloak responds with the Assertion in the SAMLResponse
>> it incorrectly uses the HTTP-Redirect binding instead of the HTTP-POST
>> binding (specified in both the AuthnRequest and the SP metadata). This
>> causes a failure because the endpoint for the SP's
>> AssertionConsumerServiceURL only expects HTTP-POST, the resulting
>> error is an invalid HTTP method failure.
>>
>> I also noticed that when I used the Web UI to examine the SP metadata
>> (Installation tab of the realm client, selecting the "SAML Metadata
>> SPSSODescriptor" format) that it did not match the SP metadata that
>> had been loaded using the client registration service. Not only wasn't
>> it the exact same metadata, but specifically it was missing several of
>> the endpoints the SP declared in it's metadata. Why isn't the metadata
>> the same and why did Keycloak drop essential endpoint/binding
>> information?
>>
>> Thanks,
>>
> Was that 1.9.0 or 1.9.2?  I thought they said that there were some bugs
> in 1.9.0 that had been fixed in 1.9.2.  Looks like they dropped 1.9.2
> final later on today.

Its not going to store the exact SP metadata file that was imported.  
Keycloak only imports SP metadata that Keycloak.  Also, the admin 
console is allowed to modify this imported metadata however it wants. I 
don't see a problem with this behavior at all.

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


From bburke at redhat.com  Sat Apr 16 10:06:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 16 Apr 2016 10:06:10 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <5711626F.60300@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
	<5711626F.60300@redhat.com>
Message-ID: <571246D2.2010406@redhat.com>



On 4/15/2016 5:51 PM, John Dennis wrote:
> On 04/15/2016 02:07 PM, Pedro Igor Silva wrote:
>
>> Like we discussed on IRC, KC relies on the ProtocolBinding attribute
>> of an AuthnRequest to decide which response binding to use. We don't
>> support AssertionConsumerServiceURL neither
>> AssertionConsumerServiceIndex. Accordingly with the specs, all those
>> attributes are optional and mutually exclusive.
>
> I don't believe that's true, they are not all mutually exclusive. Here
> is my reading of the SAML Core Spec in Section "3.4.1 Element
> <AuthnRequest>"
>
> The AssertionConsumerServiceIndex, AssertionConsumerServiceURL and
> ProtocolBinding attributes are all optional. The
> AssertionConsumerServiceIndex is mutually exclusive with the
> AssertionConsumerServiceURL attribute. The ProtocolBinding attribute
> may only be composed with the AssertionConsumerServiceURL
> attribute. Therefore the ProtocolBinding attribute is also mutually
> exclusive with the AssertionConsumerServiceIndex attribute.
>
> Here are the 5 possible legal combinations:
>
> 1) None of AssertionConsumerServiceIndex, AssertionConsumerServiceURL
> nor ProtocolBinding are supplied.
>
> 2) AssertionConsumerServiceIndex is supplied
>
> 3) AssertionConsumerServiceURL is supplied
>
> 4) AssertionConsumerServiceURL and ProtocolBinding are supplied.
>
> 5) ProtocolBinding is supplied.
>
> In the Web SSO case the SAML Profiles Spec in Section
> 4.1.2 "Profile Overview" in "Step 5. Identity Provider issues <Response>
> to Service Provider" the spec is very clear you're supposed to respond
> with an AuthnResponse using either POST or Artifact, but *never*
> Redirect. Here is the specification text:
>
> "In step 5, the identity provider issues a <Response> message to be
> delivered by the user agent to the service provider. Either the HTTP
> POST, or HTTP Artifact binding can be used to transfer the message to
> the service provider through the user agent. The message may indicate
> an error, or will include (at least) an authentication assertion. The
> HTTP Redirect binding MUST NOT be used, as the response will typically
> exceed the URL length permitted by most user agents."
>
>> In case ProtocolBinding is not provided, KC chooses on based on how
>> the AutnRequest was sent. Eg.? If sent using POST than use POST to
>> respond.
>
> See above, this is not correct.
>
> You can only respond using either HTTP-Post or Artifact. So which of the
> two do you choose? You need to follow the rules outlined above for the
> presence of the attributes in the AuthnRequest. Here is how I think you
> need to handle the 5 cases enumerated above.
>
> 1) Since nothing was specified use a default (HTTP-Post). The spec seems
> to be silent on what the default should be but HTTP-Post seems like the
> best choice.
>
> 2) Verify the AssertionConsumerServiceIndex is valid and specifies a
> binding of either HTTP-Post or Artifact, if not it's an error. If the
> ProtocolBinding attribute is also specified it's an error.
>
> 3) If only the AssertionConsumerServiceURL is specified you have to
> figure out if you're going to use HTTP-Post or Artifact. The spec is
> silent on how you determine this but a reasonable and friendly thing to
> do is scan the AssertionConsumerService endpoints the SP supplied in
> it's metadata in order [1] and select the first one which matches either
> HTTP-Post or Artifact. If none of them match use the default 
> (HTTP-Post). You must verify the AssertionConsumerServiceURL is 
> present in the SP metadata.
>
> 4) Verify the ProtocolBinding is one of HTTP-Post or Artifact, if not
> it's an error. Use the ProtocolBinding attribute for the binding and 
> the AssertionConsumerServiceURL as the destination (after validating 
> the URL is specified in the SP metadata!)
>
> 5) Verify the ProtocolBinding is one of HTTP-Post or Artifact, if not
> it's an error. The spec appears to be silent on how to determine the
> AssertionConsumerService URL. Probably the best action is something
> similar to case 3, scan the ACS endpoints in order [1] and use the first
> match.
>
> [1] See Section 2.2.3 "Complex Type IndexedEndpointType" in the SAML
> Metadata spec. concerning the isDefault flag and index values. Start
> with the default ACS as determined by the rules in Section 2.3.3 and 
> then iterate over the remainder of the ACS's. I would suggest 
> iterating in index order as opposed to metadata order.
>

I don't see any blockers here.  If you want to log a few jiras, we'll 
get to the rest in Keycloak 2.0 (RH SSO 7.1).  We will not be supporting 
Artifact binding unless a critical mass of customers ask for it.  I also 
do not see us supporting ACSI either unless asked for either.

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


From jdennis at redhat.com  Sat Apr 16 10:22:39 2016
From: jdennis at redhat.com (John Dennis)
Date: Sat, 16 Apr 2016 10:22:39 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <571246D2.2010406@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
	<5711626F.60300@redhat.com> <571246D2.2010406@redhat.com>
Message-ID: <57124AAF.4010100@redhat.com>

On 04/16/2016 10:06 AM, Bill Burke wrote:
> I don't see any blockers here.  If you want to log a few jiras, we'll
> get to the rest in Keycloak 2.0 (RH SSO 7.1).  We will not be supporting
> Artifact binding unless a critical mass of customers ask for it.  I also
> do not see us supporting ACSI either unless asked for either.

I'm not asking for KC to support ACSI or Artifact. Rather I was trying 
to clarify SAML behavior when various attributes are present in the 
AuthnRequest.


-- 
John

From jdennis at redhat.com  Sat Apr 16 10:46:51 2016
From: jdennis at redhat.com (John Dennis)
Date: Sat, 16 Apr 2016 10:46:51 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <571245A4.2090501@redhat.com>
References: <57103C1C.8060806@redhat.com>
	<802077583.51689593.1460743658059.JavaMail.zimbra@redhat.com>
	<5711626F.60300@redhat.com>
	<1642445971.51753158.1460760939001.JavaMail.zimbra@redhat.com>
	<5711B869.4030004@redhat.com> <571245A4.2090501@redhat.com>
Message-ID: <5712505B.6000303@redhat.com>

On 04/16/2016 10:01 AM, Bill Burke wrote:
> You can configure keycloak to always send a POST.  That is the
> workaround right now.

Pedro said "Force Post Binding" was the default, it does not appear to 
be, I had to manually enable "Force Post Binding" after registering the 
SAML SP, when I did enable it I got correct behavior.

I wonder if the default value of "Force Post Binding" is somehow 
dependent upon how the SP is created in KC, at the moment there are 2 
different mechanisms (client registration service vs. 
client-description-converter).

At a minimum registering a SAML SP should yield something that works 
without needing to fiddle around with non-compliant workarounds. I 
suspect this is something that will trip up many admins who already find 
SAML difficult and obscure.

Since the only 2 possible AuthnRequest response bindings for WebSSO are 
either POST or Artifact and KC does not support Artifact then why 
doesn't KC simply do POST?

The point of the discussion was to come to agreement on what KC needs to 
do to be a compliant SAML IdP so that it can interoperate with other 
SAML implementations.



-- 
John

From jdennis at redhat.com  Sat Apr 16 11:23:41 2016
From: jdennis at redhat.com (John Dennis)
Date: Sat, 16 Apr 2016 11:23:41 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <57124653.9090803@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com>
Message-ID: <571258FD.2090401@redhat.com>

On 04/16/2016 10:04 AM, Bill Burke wrote:
>>> I also noticed that when I used the Web UI to examine the SP metadata
>>> (Installation tab of the realm client, selecting the "SAML Metadata
>>> SPSSODescriptor" format) that it did not match the SP metadata that
>>> had been loaded using the client registration service. Not only wasn't
>>> it the exact same metadata, but specifically it was missing several of
>>> the endpoints the SP declared in it's metadata. Why isn't the metadata
>>> the same and why did Keycloak drop essential endpoint/binding
>>> information?

> Its not going to store the exact SP metadata file that was imported.
> Keycloak only imports SP metadata that Keycloak.  Also, the admin
> console is allowed to modify this imported metadata however it wants. I
> don't see a problem with this behavior at all.

Here is the issue. I'm an admin and I register my SP with Keycloak. But 
either because things are not working as expected or because I simply 
can't remember if I updated the SP metadata in the Keycloak IdP after I 
made a change in the SP at my end I decide to go the the Keycloak Web UI 
and check and see what Keycloak thinks my SP metadata is.

Instead of seeing what I believe my SP metadata should be I see 
something completely different and that is a red flag. I wonder why the 
metadata I load is not the same metadata Keycloak is operating on. Is 
this the source of my problems?

In particular I'm concerned about Keycloak dropping my SP's SAML endpoints.

I think what you're implying is that Keycloak will parse the SP metadata 
and retain only those parts of it which it currently understands, it 
then stores the data it picked out of the metadata in persistent storage 
and when asked to display the metadata Keycloak will read it's internal 
datastore and format it as SAML metadata. Correct?

If so what happens when Keycloak grows support for other SAML features? 
Are you then going to require every SP to re-register themselves so that 
Keycloak can parse the metadata again and rebuild it's internal data 
structures? Shouldn't after a Keycloak upgrade things just work?

Let me give you a concrete example. The SP I registered has support for 
the HTTP-Artifact binding. But the HTTP-Artifact endpoint does not show 
up when I ask Keycloak what my SP's metadata is. I'm speculating, but I 
assume what is going on is that because Keycloak didn't understand the 
HTTP-Artifact endpoint it ignored it. Now lets say Keycloak is upgraded 
to a version that supports HTTP-Artifact, it won't just work, I'll have 
to re-register every SP after the upgrade. In a production environment 
this might not even be possible. (Let's not get hung up over the use of 
Artifact in this example and whether it's an important feature to add 
down the road, the point applies to any SAML feature not currently 
understood).

So there are 2 reasons why the entire contents of original metadata 
should be preserved:

1) Diagnostics, debugging, etc.

2) Supporting upgrades.



-- 
John

From bburke at redhat.com  Sat Apr 16 14:39:40 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 16 Apr 2016 14:39:40 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <571258FD.2090401@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
Message-ID: <571286EC.5080105@redhat.com>



On 4/16/2016 11:23 AM, John Dennis wrote:
> On 04/16/2016 10:04 AM, Bill Burke wrote:
>>>> I also noticed that when I used the Web UI to examine the SP metadata
>>>> (Installation tab of the realm client, selecting the "SAML Metadata
>>>> SPSSODescriptor" format) that it did not match the SP metadata that
>>>> had been loaded using the client registration service. Not only wasn't
>>>> it the exact same metadata, but specifically it was missing several of
>>>> the endpoints the SP declared in it's metadata. Why isn't the metadata
>>>> the same and why did Keycloak drop essential endpoint/binding
>>>> information?
>
>> Its not going to store the exact SP metadata file that was imported.
>> Keycloak only imports SP metadata that Keycloak.  Also, the admin
>> console is allowed to modify this imported metadata however it wants. I
>> don't see a problem with this behavior at all.
>
> Here is the issue. I'm an admin and I register my SP with Keycloak. 
> But either because things are not working as expected or because I 
> simply can't remember if I updated the SP metadata in the Keycloak IdP 
> after I made a change in the SP at my end I decide to go the the 
> Keycloak Web UI and check and see what Keycloak thinks my SP metadata is.
>
> Instead of seeing what I believe my SP metadata should be I see 
> something completely different and that is a red flag. I wonder why 
> the metadata I load is not the same metadata Keycloak is operating on. 
> Is this the source of my problems?
>
> In particular I'm concerned about Keycloak dropping my SP's SAML 
> endpoints.
>

I don't think your concern is valid or a red flag.  Please correct me if 
I'm wrong, but there is absolutely nothing within the SP metadata file 
that defines the preferred way the client wants to communicate if there 
are multiple options defined.   Also, it is usually the IDP side that 
drives these preferences, not the client.

> I think what you're implying is that Keycloak will parse the SP 
> metadata and retain only those parts of it which it currently 
> understands, it then stores the data it picked out of the metadata in 
> persistent storage and when asked to display the metadata Keycloak 
> will read it's internal datastore and format it as SAML metadata. 
> Correct?
>

No, it parses the SP metadata file and decides how it is going to 
interact with the SP based on best practices, i.e. POST over Redirect, etc.

> If so what happens when Keycloak grows support for other SAML 
> features? Are you then going to require every SP to re-register 
> themselves so that Keycloak can parse the metadata again and rebuild 
> it's internal data structures? Shouldn't after a Keycloak upgrade 
> things just work?
>
If it works before Keycloak is upgraded, why wouldn't it work after?  I 
really don't see the admin wanting to switch to Artifact if Keycloak 
ever ends up supporting it.    Also, IMO, it is just as likely that the 
admin defines the client in the admin console and exports the SP 
metadata to be consumed by mod-auth-mellon, than for somebody to craft 
an SP metadata file and import it into Keycloak. It really depends if 
the admin is migrating from an existing SSO solution to Keycloak or not.

IMO, what the bug fixes should be are:
* Make sure "Force POST Binding" is on by default (High Priority)
* Don't support an import unless there are valid bindings.  i.e. if only 
artifact is listed, then abort import with an error. (High priority)
* Add support for ACSI and ACSU (low priority)
* Add support for Artifact Binding (very low priority, to Won't Implement)


> So there are 2 reasons why the entire contents of original metadata 
> should be preserved:
>
> 1) Diagnostics, debugging, etc.
>
> 2) Supporting upgrades.
>
I completely disagree that the entire contents need to be preserved.   
And I don't see what a Keycloak upgrade has to do with anything.


>
>

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


From pkkamos at gmail.com  Sun Apr 17 02:04:14 2016
From: pkkamos at gmail.com (Paa Kojo Konduah Amos)
Date: Sun, 17 Apr 2016 06:04:14 -0000
Subject: [keycloak-dev] java.net.ConnectException: Connection timed out
Message-ID: <007601d1986e$fa8f39d0$efadad70$@gmail.com>

Hello, Any leads on how to resolve this? ; This is happening only when you
try to access the application from a public IP. 

 

NOTE: 

-         Everything works as expected within the LAN.

-        I have not obtained a CERTIFICATE yet; I am still using the
self-generated one.

 

ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-2)
failed to turn code into token: java.net.ConnectException: Connection timed
out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160417/1747b7f7/attachment.html 

From mposolda at redhat.com  Mon Apr 18 06:23:18 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 18 Apr 2016 12:23:18 +0200
Subject: [keycloak-dev] java.net.ConnectException: Connection timed out
In-Reply-To: <007601d1986e$fa8f39d0$efadad70$@gmail.com>
References: <007601d1986e$fa8f39d0$efadad70$@gmail.com>
Message-ID: <5714B596.8080004@redhat.com>

It seems like the issue related to SSL setup. You may need to configure 
keystore and truststore (or alternatively you may need to disable 
truststore), especially since you're using self-signed certificates. See 
docs here 
http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config 
and especially the options "truststore", "truststore-password", 
"client-keystore", "client-keystore-password", "client-key-password" and 
"disable-trust-manager" .

Btv. It's better to use keycloak-user ML for questions ;)

Marek

On 17/04/16 08:04, Paa Kojo Konduah Amos wrote:
>
> Hello, Any leads on how to resolve this? ; This is happening only when 
> you try to access the application from a public IP.
>
> NOTE:
>
> - Everything works as expected within the LAN.
>
> -I have not obtained a CERTIFICATE yet; I am still using the 
> self-generated one.
>
> *ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default 
> task-2) failed to turn code into token: java.net.ConnectException: 
> Connection timed out.*
>
>
>
> _______________________________________________
> 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/20160418/5a792777/attachment.html 

From psilva at redhat.com  Mon Apr 18 07:23:19 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 18 Apr 2016 07:23:19 -0400 (EDT)
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <571286EC.5080105@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
	<571286EC.5080105@redhat.com>
Message-ID: <924597557.53415089.1460978599537.JavaMail.zimbra@redhat.com>

> IMO, what the bug fixes should be are:
> * Make sure "Force POST Binding" is on by default (High Priority)

As John pointed out ...

Don't you think that in 2.0 you can just do POST and remove that "Force POST Binding" switch ?

> * Don't support an import unless there are valid bindings.  i.e. if only
> artifact is listed, then abort import with an error. (High priority)
> * Add support for ACSI and ACSU (low priority)
> * Add support for Artifact Binding (very low priority, to Won't Implement)
> 
> 
> --
> 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 Apr 18 08:47:43 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 18 Apr 2016 08:47:43 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <924597557.53415089.1460978599537.JavaMail.zimbra@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
	<571286EC.5080105@redhat.com>
	<924597557.53415089.1460978599537.JavaMail.zimbra@redhat.com>
Message-ID: <5714D76F.9010506@redhat.com>



On 4/18/2016 7:23 AM, Pedro Igor Silva wrote:
>> IMO, what the bug fixes should be are:
>> * Make sure "Force POST Binding" is on by default (High Priority)
> As John pointed out ...
>
> Don't you think that in 2.0 you can just do POST and remove that "Force POST Binding" switch ?

I would just do it now.  It is a easy fix and makes configuration that 
much simpler.  If you agree I'll just change it.

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


From psilva at redhat.com  Mon Apr 18 09:03:11 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 18 Apr 2016 09:03:11 -0400 (EDT)
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <5714D76F.9010506@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
	<571286EC.5080105@redhat.com>
	<924597557.53415089.1460978599537.JavaMail.zimbra@redhat.com>
	<5714D76F.9010506@redhat.com>
Message-ID: <1665979137.53452124.1460984591351.JavaMail.zimbra@redhat.com>

+1

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "John Dennis" <jdennis at redhat.com>, keycloak-dev at lists.jboss.org, "Nathan Kinder" <nkinder at redhat.com>
Sent: Monday, April 18, 2016 9:47:43 AM
Subject: Re: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding



On 4/18/2016 7:23 AM, Pedro Igor Silva wrote:
>> IMO, what the bug fixes should be are:
>> * Make sure "Force POST Binding" is on by default (High Priority)
> As John pointed out ...
>
> Don't you think that in 2.0 you can just do POST and remove that "Force POST Binding" switch ?

I would just do it now.  It is a easy fix and makes configuration that 
much simpler.  If you agree I'll just change it.

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


From sthorger at redhat.com  Mon Apr 18 09:26:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Apr 2016 15:26:48 +0200
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <1665979137.53452124.1460984591351.JavaMail.zimbra@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
	<571286EC.5080105@redhat.com>
	<924597557.53415089.1460978599537.JavaMail.zimbra@redhat.com>
	<5714D76F.9010506@redhat.com>
	<1665979137.53452124.1460984591351.JavaMail.zimbra@redhat.com>
Message-ID: <CAJgngAet4DVjAiaWPLdgZZXmu7aUs=x_8PNhv99uiabfor_6dA@mail.gmail.com>

We're way past feature freeze and need to carefully consider including more
changes for 1.9.x.

Unless this is required, which from my understanding it's not, we create a
JIRA issue for 2.x and post-pone.

On 18 April 2016 at 15:03, Pedro Igor Silva <psilva at redhat.com> wrote:

> +1
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "John Dennis" <jdennis at redhat.com>, keycloak-dev at lists.jboss.org,
> "Nathan Kinder" <nkinder at redhat.com>
> Sent: Monday, April 18, 2016 9:47:43 AM
> Subject: Re: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong
> binding
>
>
>
> On 4/18/2016 7:23 AM, Pedro Igor Silva wrote:
> >> IMO, what the bug fixes should be are:
> >> * Make sure "Force POST Binding" is on by default (High Priority)
> > As John pointed out ...
> >
> > Don't you think that in 2.0 you can just do POST and remove that "Force
> POST Binding" switch ?
>
> I would just do it now.  It is a easy fix and makes configuration that
> much simpler.  If you agree I'll just change it.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160418/d2241149/attachment-0001.html 

From bburke at redhat.com  Mon Apr 18 09:28:50 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 18 Apr 2016 09:28:50 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <CAJgngAet4DVjAiaWPLdgZZXmu7aUs=x_8PNhv99uiabfor_6dA@mail.gmail.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
	<571286EC.5080105@redhat.com>
	<924597557.53415089.1460978599537.JavaMail.zimbra@redhat.com>
	<5714D76F.9010506@redhat.com>
	<1665979137.53452124.1460984591351.JavaMail.zimbra@redhat.com>
	<CAJgngAet4DVjAiaWPLdgZZXmu7aUs=x_8PNhv99uiabfor_6dA@mail.gmail.com>
Message-ID: <5714E112.4070002@redhat.com>

Its spec compliance, a quick fix, and makes things simpler.

On 4/18/2016 9:26 AM, Stian Thorgersen wrote:
> We're way past feature freeze and need to carefully consider including 
> more changes for 1.9.x.
>
> Unless this is required, which from my understanding it's not, we 
> create a JIRA issue for 2.x and post-pone.
>
> On 18 April 2016 at 15:03, Pedro Igor Silva <psilva at redhat.com 
> <mailto:psilva at redhat.com>> wrote:
>
>     +1
>
>     ----- Original Message -----
>     From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>     To: "Pedro Igor Silva" <psilva at redhat.com <mailto:psilva at redhat.com>>
>     Cc: "John Dennis" <jdennis at redhat.com
>     <mailto:jdennis at redhat.com>>, keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>, "Nathan Kinder"
>     <nkinder at redhat.com <mailto:nkinder at redhat.com>>
>     Sent: Monday, April 18, 2016 9:47:43 AM
>     Subject: Re: [keycloak-dev] Keycloak's SAML AuthnResponse uses
>     wrong binding
>
>
>
>     On 4/18/2016 7:23 AM, Pedro Igor Silva wrote:
>     >> IMO, what the bug fixes should be are:
>     >> * Make sure "Force POST Binding" is on by default (High Priority)
>     > As John pointed out ...
>     >
>     > Don't you think that in 2.0 you can just do POST and remove that
>     "Force POST Binding" switch ?
>
>     I would just do it now.  It is a easy fix and makes configuration that
>     much simpler.  If you agree I'll just change it.
>
>     --
>     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
>
>

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

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

From wadahiro at gmail.com  Tue Apr 19 05:00:46 2016
From: wadahiro at gmail.com (wadahiro)
Date: Tue, 19 Apr 2016 18:00:46 +0900
Subject: [keycloak-dev] MaxBuffer setting in SamlFilter
Message-ID: <CAPq3NeG0w=OQPHpTBU5er98874yQTMsSWeTHH+qhxBGm27yh-g@mail.gmail.com>

Hi,

I had evaluated Keyloak SAML Client Adapter a month ago.
As a result, I noticed that 'SamlFilter.java' does not support
maxBuffer setting. It was hard-coded with '100000' currently.
I want to propose that we can set it in 'WEB-INF/web.xml', how about
you ? I can send a pull request with the following changes.

https://github.com/wadahiro/keycloak/commit/0d283caccf5369ae6c48c5530e1a23955f29c64d

Regards,
Hiroyuki Wada

From gambol99 at gmail.com  Tue Apr 19 06:34:28 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 19 Apr 2016 11:34:28 +0100
Subject: [keycloak-dev] Refresh Token Revoke Endpoint
Message-ID: <CA+AP+fOf6eB2fxXBD5AkVNmQkYqjjb7==Ktwu9RLca6QW3Mg=w@mail.gmail.com>

Hiya

I've been searching around but haven't come across anything yet. Does
Keycloak support a revoke endpoint? for revoking refresh tokens ... i.e. curl
https://accounts.google.com/o/oauth2/revoke?token={token} ..

Rohith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160419/d44aca13/attachment.html 

From Jukka.Sirvio at mipro.fi  Tue Apr 19 07:22:08 2016
From: Jukka.Sirvio at mipro.fi (=?iso-8859-1?Q?Jukka_Sirvi=F6?=)
Date: Tue, 19 Apr 2016 11:22:08 +0000
Subject: [keycloak-dev] silent ssl error in debug level
Message-ID: <5647d97a6ff9496e815f3b715bc9248c@MIPROEXCH01.mipro.local>

Hello,
Anybody have any clue what could be causing this "silent exception" when DEBUG level logging is used, to SP's log. IOException is written to log all the time. Thus SAML authentication is working ok / normally. Using SSL (https) public addresses both with IDP and SP, along with signed & encrypted SAML assertions. Public certificates are good and ok!

2016-04-19 13:25:26,441 DEBUG [io.undertow.request.io] (default I/O-8) UT005013: An IOException occurred: java.io.IOException: javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
at io.undertow.protocols.ssl.SslConduit.notifyReadClosed(SslConduit.java:577)
at io.undertow.protocols.ssl.SslConduit.terminateReads(SslConduit.java:178)
at org.xnio.conduits.ConduitStreamSourceChannel.close(ConduitStreamSourceChannel.java:168)
at org.xnio.IoUtils.safeClose(IoUtils.java:134)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.forceTermination(ReadReadyHandler.java:58)
at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.forceTermination(SslConduit.java:1091)
at org.xnio.nio.NioSocketConduit.forceTermination(NioSocketConduit.java:105)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
Caused by: javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634)
at sun.security.ssl.SSLEngineImpl.closeInbound(SSLEngineImpl.java:1561)
at io.undertow.protocols.ssl.SslConduit.notifyReadClosed(SslConduit.java:575)
... 7 more



________________________________

T?m? s?hk?postiviesti (liitteineen) saattaa sis?lt?? luottamuksellista tietoa, joka on tarkoitettu
vain vastaanottajalleen. Jos et ole oikea vastaanottaja, ilmoita viestin l?hett?j?lle tapahtuneesta
virheest? ja tuhoa viesti v?litt?m?sti. Viestin luvaton julkaiseminen, kopioiminen, jakelu tai muu
k?ytt? tai toimenpiteisiin ryhtyminen sen perusteella on ehdottomasti kielletty.

This message (including any attachments) may contain confidential information intended for
the person or entity to which it is addressed. If you are not the intended recipient, notify the
sender and delete this message immediately. Notice that disclosing, copying, distributing or any
other use of the message and its information, or taking any action based on it, is strictly prohibited.

________________________________


From bburke at redhat.com  Tue Apr 19 09:03:05 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 19 Apr 2016 09:03:05 -0400
Subject: [keycloak-dev] MaxBuffer setting in SamlFilter
In-Reply-To: <CAPq3NeG0w=OQPHpTBU5er98874yQTMsSWeTHH+qhxBGm27yh-g@mail.gmail.com>
References: <CAPq3NeG0w=OQPHpTBU5er98874yQTMsSWeTHH+qhxBGm27yh-g@mail.gmail.com>
Message-ID: <57162C89.2010003@redhat.com>

Should be a configuration switch in the keycloak-saml.xml file and set 
across all adapters.

On 4/19/2016 5:00 AM, wadahiro wrote:
> Hi,
>
> I had evaluated Keyloak SAML Client Adapter a month ago.
> As a result, I noticed that 'SamlFilter.java' does not support
> maxBuffer setting. It was hard-coded with '100000' currently.
> I want to propose that we can set it in 'WEB-INF/web.xml', how about
> you ? I can send a pull request with the following changes.
>
> https://github.com/wadahiro/keycloak/commit/0d283caccf5369ae6c48c5530e1a23955f29c64d
>
> Regards,
> Hiroyuki Wada
> _______________________________________________
> 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 carreraariel at gmail.com  Tue Apr 19 09:48:09 2016
From: carreraariel at gmail.com (Ariel Carrera)
Date: Tue, 19 Apr 2016 10:48:09 -0300
Subject: [keycloak-dev] Refresh Token Revoke Endpoint
In-Reply-To: <CA+AP+fOf6eB2fxXBD5AkVNmQkYqjjb7==Ktwu9RLca6QW3Mg=w@mail.gmail.com>
References: <CA+AP+fOf6eB2fxXBD5AkVNmQkYqjjb7==Ktwu9RLca6QW3Mg=w@mail.gmail.com>
Message-ID: <CAFzO_6cK9V0zObjVs=U4teEn+WMc_5Ttg-vAzHBu4MO0SM6P2g@mail.gmail.com>

+1
El 19/4/2016 7:34, "gambol" <gambol99 at gmail.com> escribi?:

> Hiya
>
> I've been searching around but haven't come across anything yet. Does
> Keycloak support a revoke endpoint? for revoking refresh tokens ... i.e. curl
> https://accounts.google.com/o/oauth2/revoke?token={token} ..
>
> Rohith
>
> _______________________________________________
> 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/20160419/f630dc4a/attachment.html 

From gambol99 at gmail.com  Tue Apr 19 10:06:10 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 19 Apr 2016 15:06:10 +0100
Subject: [keycloak-dev] Refresh Token Revoke Endpoint
In-Reply-To: <CAFzO_6cK9V0zObjVs=U4teEn+WMc_5Ttg-vAzHBu4MO0SM6P2g@mail.gmail.com>
References: <CA+AP+fOf6eB2fxXBD5AkVNmQkYqjjb7==Ktwu9RLca6QW3Mg=w@mail.gmail.com>
	<CAFzO_6cK9V0zObjVs=U4teEn+WMc_5Ttg-vAzHBu4MO0SM6P2g@mail.gmail.com>
Message-ID: <CA+AP+fOrBvfqv7vmBA_OqX-CZT5T=XHTBG=-agkTMKwt1=cpoQ@mail.gmail.com>

Ok ... I found https://issues.jboss.org/browse/KEYCLOAK-2476, which
suggests POST {realm}/protocol/openid-connect/logout, though i've not tried
yet ... Is this standard? should there be a 'revocation_endpoint' in
the .well-known/openid-configuration discovery? ... I noticed the parameter
names i.e. ?token=<TOKEN> vs ?refresh_token=<TOKEN> are different than
Google, Salesforce etc (as we wanted to support other openid providers
along side keycloak)

On Tue, Apr 19, 2016 at 2:48 PM, Ariel Carrera <carreraariel at gmail.com>
wrote:

> +1
> El 19/4/2016 7:34, "gambol" <gambol99 at gmail.com> escribi?:
>
>> Hiya
>>
>> I've been searching around but haven't come across anything yet. Does
>> Keycloak support a revoke endpoint? for revoking refresh tokens ... i.e. curl
>> https://accounts.google.com/o/oauth2/revoke?token={token} ..
>>
>> Rohith
>>
>> _______________________________________________
>> 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/20160419/bc9d9c9d/attachment-0001.html 

From mposolda at redhat.com  Tue Apr 19 15:58:00 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 19 Apr 2016 21:58:00 +0200
Subject: [keycloak-dev] Login modules in different package in 1.9.x and
	master
Message-ID: <57168DC8.9010101@redhat.com>

Currently the JAAS classes (DirectAccessGrantsLoginModule, 
BearerTokenLoginModule etc) are in different package in 1.9.x and in 
master. Previously they were in package "org.keycloak.adapters.jass" and 
they are still there in 1.9.x branch. However in master they were moved 
to package "org.keycloak.adapters" .

Were they moved by accident or by purpose? IMO we should have unified 
package in both branches to avoid future issues with backwards 
compatibility between Keycloak 1.X and 2.X. My vote is to keep the old 
package "org.keycloak.adapters.jaas" in both places to keep backwards 
compatibility with older versions than 1.9.2 . WDYT?

Marek

From bburke at redhat.com  Tue Apr 19 16:01:02 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 19 Apr 2016 16:01:02 -0400
Subject: [keycloak-dev] Login modules in different package in 1.9.x and
 master
In-Reply-To: <57168DC8.9010101@redhat.com>
References: <57168DC8.9010101@redhat.com>
Message-ID: <57168E7E.2080809@redhat.com>

This was an accident.

On 4/19/2016 3:58 PM, Marek Posolda wrote:
> Currently the JAAS classes (DirectAccessGrantsLoginModule,
> BearerTokenLoginModule etc) are in different package in 1.9.x and in
> master. Previously they were in package "org.keycloak.adapters.jass" and
> they are still there in 1.9.x branch. However in master they were moved
> to package "org.keycloak.adapters" .
>
> Were they moved by accident or by purpose? IMO we should have unified
> package in both branches to avoid future issues with backwards
> compatibility between Keycloak 1.X and 2.X. My vote is to keep the old
> package "org.keycloak.adapters.jaas" in both places to keep backwards
> compatibility with older versions than 1.9.2 . WDYT?
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From mposolda at redhat.com  Tue Apr 19 16:08:10 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 19 Apr 2016 22:08:10 +0200
Subject: [keycloak-dev] Login modules in different package in 1.9.x and
 master
In-Reply-To: <57168E7E.2080809@redhat.com>
References: <57168DC8.9010101@redhat.com> <57168E7E.2080809@redhat.com>
Message-ID: <5716902A.9010403@redhat.com>

Thanks, I will send PR to master to move them back.

Marek

On 19/04/16 22:01, Bill Burke wrote:
> This was an accident.
>
> On 4/19/2016 3:58 PM, Marek Posolda wrote:
>> Currently the JAAS classes (DirectAccessGrantsLoginModule,
>> BearerTokenLoginModule etc) are in different package in 1.9.x and in
>> master. Previously they were in package "org.keycloak.adapters.jass" and
>> they are still there in 1.9.x branch. However in master they were moved
>> to package "org.keycloak.adapters" .
>>
>> Were they moved by accident or by purpose? IMO we should have unified
>> package in both branches to avoid future issues with backwards
>> compatibility between Keycloak 1.X and 2.X. My vote is to keep the old
>> package "org.keycloak.adapters.jaas" in both places to keep backwards
>> compatibility with older versions than 1.9.2 . WDYT?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From wadahiro at gmail.com  Tue Apr 19 23:02:39 2016
From: wadahiro at gmail.com (wadahiro)
Date: Wed, 20 Apr 2016 12:02:39 +0900
Subject: [keycloak-dev] MaxBuffer setting in SamlFilter
In-Reply-To: <57162C89.2010003@redhat.com>
References: <CAPq3NeG0w=OQPHpTBU5er98874yQTMsSWeTHH+qhxBGm27yh-g@mail.gmail.com>
	<57162C89.2010003@redhat.com>
Message-ID: <CAPq3NeGMmmnTbh4WorYSB0hvAc=x3LcxChv9MzkV32ou0iPfLg@mail.gmail.com>

It looks like hard to set it across all adapters because the
bufferSize is set and used by external dependent library of the SAML
Adapter except for SamlFilter.
For example, the bufferSize is used in the Undertow class
'io.undertow.servlet.util.SavedRequest' when we use Wildfly SAML
Adapter as follows.

https://github.com/undertow-io/undertow/blob/1.3.21.Final/servlet/src/main/java/io/undertow/servlet/util/SavedRequest.java#L72

I think the value is read-only and cannot set it from
'WildflySamlSessionStore.java' in Wildfly SAML Adapter of Keycloak.

On Tue, Apr 19, 2016 at 10:03 PM, Bill Burke <bburke at redhat.com> wrote:
> Should be a configuration switch in the keycloak-saml.xml file and set
> across all adapters.
>
> On 4/19/2016 5:00 AM, wadahiro wrote:
>> Hi,
>>
>> I had evaluated Keyloak SAML Client Adapter a month ago.
>> As a result, I noticed that 'SamlFilter.java' does not support
>> maxBuffer setting. It was hard-coded with '100000' currently.
>> I want to propose that we can set it in 'WEB-INF/web.xml', how about
>> you ? I can send a pull request with the following changes.
>>
>> https://github.com/wadahiro/keycloak/commit/0d283caccf5369ae6c48c5530e1a23955f29c64d
>>
>> Regards,
>> Hiroyuki Wada
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From psilva at redhat.com  Wed Apr 20 08:22:04 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 20 Apr 2016 08:22:04 -0400 (EDT)
Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;
 ECP won't work
In-Reply-To: <2032008930.51658060.1460738834983.JavaMail.zimbra@redhat.com>
References: <5710F507.8040200@redhat.com>
	<1336365939.51656522.1460738443794.JavaMail.zimbra@redhat.com>
	<2032008930.51658060.1460738834983.JavaMail.zimbra@redhat.com>
Message-ID: <1659572305.54813272.1461154924177.JavaMail.zimbra@redhat.com>

Hi John,

   I've added the SOAP binding to the list of SingleSignOnService:

   <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost:8080/auth/realms/saml-demo/protocol/saml"/>
   <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost:8080/auth/realms/saml-demo/protocol/saml"/>
   <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="http://localhost:8080/auth/realms/saml-demo/protocol/saml"/>

Regards.
Pedro Igor   

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "John Dennis" <jdennis at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>
Sent: Friday, April 15, 2016 1:47:14 PM
Subject: Re: [keycloak-dev] missing SingleSignOnService SOAP binding; ECP won't work

Btw, created https://issues.jboss.org/browse/KEYCLOAK-2835.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "John Dennis" <jdennis at redhat.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>
Sent: Friday, April 15, 2016 1:40:43 PM
Subject: Re: [keycloak-dev] missing SingleSignOnService SOAP binding; ECP won't work

Hi John,

    I think we never added SOAP to IdP metadata. I pretty sure we did all those ECP tests without it.

    In any case, I'm going to change IdP Metadata to advertise the SOAP binding.

Regards.
Pedro Igor

----- Original Message -----
From: "John Dennis" <jdennis at redhat.com>
To: "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>, "Adam Young" <ayoung at redhat.com>
Sent: Friday, April 15, 2016 11:04:55 AM
Subject: [keycloak-dev] missing SingleSignOnService SOAP binding;	ECP won't work

Using keycloak-1.9.0.Final only the HTTP-POST and HTTP-Redirect bindings 
are advertised in the IdP Metadata for SingleSignOnService.

The SOAP SingleSignOnService was added when it was discovered to be 
missing in the 1.8 cycle, or so I thought. Did it get added in a 
different release or did it get lost somehow?

Anyway, it's really important. SAML ECP won't work unless you advertise 
support for it.


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

From bburke at redhat.com  Wed Apr 20 09:07:42 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 20 Apr 2016 09:07:42 -0400
Subject: [keycloak-dev] MaxBuffer setting in SamlFilter
In-Reply-To: <CAPq3NeGMmmnTbh4WorYSB0hvAc=x3LcxChv9MzkV32ou0iPfLg@mail.gmail.com>
References: <CAPq3NeG0w=OQPHpTBU5er98874yQTMsSWeTHH+qhxBGm27yh-g@mail.gmail.com>
	<57162C89.2010003@redhat.com>
	<CAPq3NeGMmmnTbh4WorYSB0hvAc=x3LcxChv9MzkV32ou0iPfLg@mail.gmail.com>
Message-ID: <57177F1E.4040903@redhat.com>

log a jira then and we'll get to it sometime when we get back to 2.0 
development.  I can't accept a fix only for one place.

On 4/19/2016 11:02 PM, wadahiro wrote:
> It looks like hard to set it across all adapters because the
> bufferSize is set and used by external dependent library of the SAML
> Adapter except for SamlFilter.
> For example, the bufferSize is used in the Undertow class
> 'io.undertow.servlet.util.SavedRequest' when we use Wildfly SAML
> Adapter as follows.
>
> https://github.com/undertow-io/undertow/blob/1.3.21.Final/servlet/src/main/java/io/undertow/servlet/util/SavedRequest.java#L72
>
> I think the value is read-only and cannot set it from
> 'WildflySamlSessionStore.java' in Wildfly SAML Adapter of Keycloak.
>
> On Tue, Apr 19, 2016 at 10:03 PM, Bill Burke <bburke at redhat.com> wrote:
>> Should be a configuration switch in the keycloak-saml.xml file and set
>> across all adapters.
>>
>> On 4/19/2016 5:00 AM, wadahiro wrote:
>>> Hi,
>>>
>>> I had evaluated Keyloak SAML Client Adapter a month ago.
>>> As a result, I noticed that 'SamlFilter.java' does not support
>>> maxBuffer setting. It was hard-coded with '100000' currently.
>>> I want to propose that we can set it in 'WEB-INF/web.xml', how about
>>> you ? I can send a pull request with the following changes.
>>>
>>> https://github.com/wadahiro/keycloak/commit/0d283caccf5369ae6c48c5530e1a23955f29c64d
>>>
>>> Regards,
>>> Hiroyuki Wada
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From Jelmer.van.Amen at crv4all.com  Thu Apr 21 03:37:37 2016
From: Jelmer.van.Amen at crv4all.com (Jelmer van Amen)
Date: Thu, 21 Apr 2016 07:37:37 +0000
Subject: [keycloak-dev] Providing a custom entityId for a SAML identity
	broker
Message-ID: <AM3PR07MB07264B1FD67D7AB2B67A6D7FE06E0@AM3PR07MB0726.eurprd07.prod.outlook.com>

Hi all,

Using keycloak 1.9.1, we use an external identity broker which uses SAML (the dutch government). Now we would like to use the saml implementation in keycloak.  For this to function, we need to call our provider with a SAML request containing a specific entityID ("urn:nl:eherkenning:DV:00000003123456780000:entities:9999") instead of getEntityId(uriInfo, realm) as currently used in the SAMLIdentityProvider. Now my question is two-fold. Is there any reason why the entityId is as specified as of speaking and secondly, am I correct in stating that the only way to change this behavior would be to provide a selfwritten different identity broker? Or would a (selfwritten) patch be sufficient to provide this as an optional parameter to the current SAMLIdentityProvider?

Kind regards,
Jelmer
This message is subject to the following E-mail Disclaimer. (http://www.crv4all.com/disclaimer-email/) CRV Holding B.V. seats according to the articles of association in Arnhem, Dutch trade number 09125050.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160421/98b8dbaa/attachment-0001.html 

From mposolda at redhat.com  Thu Apr 21 03:58:52 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 21 Apr 2016 09:58:52 +0200
Subject: [keycloak-dev] 2 mechanisms to configure UserFederationProvider
Message-ID: <5718883C.20400@redhat.com>

Currently we have 2 mechanisms to configure generic UserFederation 
providers.

1) The "old" way, which is using the simple list of strings - 
UserFederationProviderFactory.getConfigurationOptions()

2) The "new" and more flexible way based on ConfiguredProvider.

Should we remove the old way for the Keycloak 2.X ? If yes, then maybe 
even for 1.X we can deprecate 
UserFederationProviderFactory.getConfigurationOptions() to notify people 
that it will be removed in future versions? I know there will be more 
changes, but if we know at 100% that this one will be removed, it's 
maybe not bad to deprecate even now?

Marek

From jdennis at redhat.com  Thu Apr 21 19:57:04 2016
From: jdennis at redhat.com (John Dennis)
Date: Thu, 21 Apr 2016 19:57:04 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <5714E112.4070002@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
	<571286EC.5080105@redhat.com>
	<924597557.53415089.1460978599537.JavaMail.zimbra@redhat.com>
	<5714D76F.9010506@redhat.com>
	<1665979137.53452124.1460984591351.JavaMail.zimbra@redhat.com>
	<CAJgngAet4DVjAiaWPLdgZZXmu7aUs=x_8PNhv99uiabfor_6dA@mail.gmail.com>
	<5714E112.4070002@redhat.com>
Message-ID: <571968D0.2040204@redhat.com>

On 04/18/2016 09:28 AM, Bill Burke wrote:
> Its spec compliance, a quick fix, and makes things simpler.

Sorry for the delay in responding, I was out on PTO.

Thank you for making the change.

Spec compliance should always be a priority.

>
> On 4/18/2016 9:26 AM, Stian Thorgersen wrote:
>> We're way past feature freeze and need to carefully consider including
>> more changes for 1.9.x.
>>
>> Unless this is required, which from my understanding it's not, we
>> create a JIRA issue for 2.x and post-pone.
>>
>> On 18 April 2016 at 15:03, Pedro Igor Silva <psilva at redhat.com
>> <mailto:psilva at redhat.com>> wrote:
>>
>>     +1
>>
>>     ----- Original Message -----
>>     From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>     To: "Pedro Igor Silva" <psilva at redhat.com <mailto:psilva at redhat.com>>
>>     Cc: "John Dennis" <<mailto:jdennis at redhat.com>jdennis at redhat.com>,
>>     keycloak-dev at lists.jboss.org
>>     <mailto:keycloak-dev at lists.jboss.org>, "Nathan Kinder"
>>     <nkinder at redhat.com <mailto:nkinder at redhat.com>>
>>     Sent: Monday, April 18, 2016 9:47:43 AM
>>     Subject: Re: [keycloak-dev] Keycloak's SAML AuthnResponse uses
>>     wrong binding
>>
>>
>>
>>     On 4/18/2016 7:23 AM, Pedro Igor Silva wrote:
>>     >> IMO, what the bug fixes should be are:
>>     >> * Make sure "Force POST Binding" is on by default (High Priority)
>>     > As John pointed out ...
>>     >
>>     > Don't you think that in 2.0 you can just do POST and remove that
>>     "Force POST Binding" switch ?
>>
>>     I would just do it now.  It is a easy fix and makes configuration that
>>     much simpler.  If you agree I'll just change it.
>>
>>     --
>>     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
>>
>>
>
> --
> 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
>


-- 
John

From jdennis at redhat.com  Thu Apr 21 20:02:56 2016
From: jdennis at redhat.com (John Dennis)
Date: Thu, 21 Apr 2016 20:02:56 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <571286EC.5080105@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
	<571286EC.5080105@redhat.com>
Message-ID: <57196A30.10600@redhat.com>

On 04/16/2016 02:39 PM, Bill Burke wrote:

Sorry for the delay in responding, I was out on PTO.

> On 4/16/2016 11:23 AM, John Dennis wrote:
>> On 04/16/2016 10:04 AM, Bill Burke wrote:
>>>>> I also noticed that when I used the Web UI to examine the SP metadata
>>>>> (Installation tab of the realm client, selecting the "SAML Metadata
>>>>> SPSSODescriptor" format) that it did not match the SP metadata that
>>>>> had been loaded using the client registration service. Not only wasn't
>>>>> it the exact same metadata, but specifically it was missing several of
>>>>> the endpoints the SP declared in it's metadata. Why isn't the metadata
>>>>> the same and why did Keycloak drop essential endpoint/binding
>>>>> information?
>>
>>> Its not going to store the exact SP metadata file that was imported.
>>> Keycloak only imports SP metadata that Keycloak.  Also, the admin
>>> console is allowed to modify this imported metadata however it wants. I
>>> don't see a problem with this behavior at all.
>>
>> Here is the issue. I'm an admin and I register my SP with Keycloak.
>> But either because things are not working as expected or because I
>> simply can't remember if I updated the SP metadata in the Keycloak IdP
>> after I made a change in the SP at my end I decide to go the the
>> Keycloak Web UI and check and see what Keycloak thinks my SP metadata is.
>>
>> Instead of seeing what I believe my SP metadata should be I see
>> something completely different and that is a red flag. I wonder why
>> the metadata I load is not the same metadata Keycloak is operating on.
>> Is this the source of my problems?
>>
>> In particular I'm concerned about Keycloak dropping my SP's SAML
>> endpoints.
>>
>
> I don't think your concern is valid or a red flag.

Let me try to explain why an IdP modifying an SP's metadata is a concern.

As an illustration of the problem I've attached the SP metadata I loaded 
into Keycloak (myapp_sp_metadata.xml) and what Keycloak reports as the 
SP's metadata when queried from the client installation tab in the "SAML 
Metadata SPSSODescriptor" format. Here are where the metadata differs 
between the actual SP metadata and Keycloak's version of the SP metadata:

1) Keycloak has added a protocolSupportEnumeration for 
urn:oasis:names:tc:SAML:1.1:protocol which the SP never reported support 
for.

2) Keycloak has dropped the x509 encryption information.

3) Keycloak has dropped the SingleLogoutService using the HTTP-Redirect 
binding.

4) Keycloak has dropped the AssertionConsumerService using the 
HTTP-Artifact binding.

5) Keycloak has dropped the AssertionConsumerService using the PAOS binding.

This is clearly not what the SP reported to the IdP and I continue to 
believe this is a problem. IdP's are not permitted to alter the SP 
configuration information, rather an IdP is supposed to use the SP 
information verbatim (provided the IdP trusts the metadata).

It is common practice in SAML for admins to examine metadata. Why? 
Because most SAML problems are the result of incorrect metadata. When 
things aren't working as expected the first course of action should be 
to check the loaded metadata because the metadata drives the entire 
relationship between entities. A mistake in the metadata will certainly 
throw things into the weeds. Something not working? Check the metadata! 
If the IdP reports metadata different than provided by the SP then that 
absolutely will raise red flags.

> Please correct me if
> I'm wrong, but there is absolutely nothing within the SP metadata file
> that defines the preferred way the client wants to communicate if there
> are multiple options defined.

Actually the SP does indicate it's default AssertionConsumerService, 
it's desire for signed responses, encrypted responses, etc. in it's 
metadata. The IdP is supposed to honor them if it's able.

> Also, it is usually the IDP side that
> drives these preferences, not the client.

The IdP must respect what the SP reported.

Let me give another example. Some SAML bindings require the Destination 
attribute. But if the IdP has thrown away the binding endpoint for an SP 
how can it set the Destination attribute?

Also the IdP is supposed to validate the AssertionConsumerServiceURL 
against the value supplied in the SP metadata.

>
>> I think what you're implying is that Keycloak will parse the SP
>> metadata and retain only those parts of it which it currently
>> understands, it then stores the data it picked out of the metadata in
>> persistent storage and when asked to display the metadata Keycloak
>> will read it's internal datastore and format it as SAML metadata.
>> Correct?
>>
>
> No, it parses the SP metadata file and decides how it is going to
> interact with the SP based on best practices, i.e. POST over Redirect, etc.
>
>> If so what happens when Keycloak grows support for other SAML
>> features? Are you then going to require every SP to re-register
>> themselves so that Keycloak can parse the metadata again and rebuild
>> it's internal data structures? Shouldn't after a Keycloak upgrade
>> things just work?
>>
> If it works before Keycloak is upgraded, why wouldn't it work after?

It's not a question of features no longer working, but rather the 
inability of new features to work after an upgrade without requiring the 
all SP's to register once again so that Keycloak can read information 
which is now necessary but was formerly discarded [1].

Simple. Let's use encryption as an example. I'm guessing Keycloak does 
not currently support receiving encrypted requests because Keycloak has 
deleted the encryption information from the SP. Now lets say in a later 
release Keycloak supports encrypted requests. How are you going to 
decrypt the request if you didn't preserve the encryption parameters the 
SP provided to you in it's metadata? Are you going to require every SP 
to register themselves with Keycloak again? The same holds true for 
other features.

[1] I'm still working on the assumption Keycloak does not preserve the 
SP metadata verbatim but rather parses it and stores processed data 
instead. The SAML IdP's I'm most familiar with (Shibboleth V3 and 
Ipsilon) store the metadata and parse the stored metadata each time an 
entity is loaded. This allows them to accurately report the metadata and 
respond to bug fixes and feature upgrades when a new software version is 
installed because it's working from the canonical source description of 
the entity (e.g. the metadata).

> I really don't see the admin wanting to switch to Artifact if Keycloak
> ever ends up supporting it.    Also, IMO, it is just as likely that the
> admin defines the client in the admin console and exports the SP
> metadata to be consumed by mod-auth-mellon, than for somebody to craft
> an SP metadata file and import it into Keycloak.

Keycloak should never be in the business of generating an SP's metadata.

How can an IdP possibly know anything about an SP? IdP's cannot define 
what an SP is or how it is configured. Suggesting an IdP can know a 
prori how an SP is configured or what it's capabilities are is way 
outside normal SAML practice and is fundamentally backwards. If IdP's 
were capable of knowing enough about a SP such that it could generate 
the SP's metadata then why would metadata exchange even exist? Metadata 
and metadata exchange is a fundamental building block of SAML with it's 
own specification and exists for a reason.

Let me give a concrete example of why your suggestion that Keycloak 
would generate the metadata for a mellon SP is flawed. Up until recently 
mellon did not support ECP. ECP requires the SP export an 
AssertionConsumerService with a PAOS binding. So how is Keycloak going 
to generate the correct metadata for a mellon SP if it doesn't know what 
the version of mellon is and the versions of the libraries that mellon 
links with on the SP? Those are critical components of what mellon's 
capabilities are. So how is Keycloak as an IdP which is completely 
independent of an SP going to generate correct metadata? It's completely 
backwards to normal SAML. IdP's don't generate SP metadata, rather IdP's 
consume SP metadata. How is an IdP going to know an SP's security 
requirements? (e.g. signed responses, encrypted responses, validity 
period, etc.) How is an IdP going to know what the default service 
endpoint is or the correct ordering of endpoints? Don't forget that an 
SP may communicate with multiple IdP's thus the SP metadata must be 
valid across a set of IdP's (the other IdP's will be unknown to Keycloak).

> It really depends if
> the admin is migrating from an existing SSO solution to Keycloak or not.
>
> IMO, what the bug fixes should be are:
> * Make sure "Force POST Binding" is on by default (High Priority)
> * Don't support an import unless there are valid bindings.  i.e. if only
> artifact is listed, then abort import with an error. (High priority)
> * Add support for ACSI and ACSU (low priority)
> * Add support for Artifact Binding (very low priority, to Won't Implement)
>
>
>> So there are 2 reasons why the entire contents of original metadata
>> should be preserved:
>>
>> 1) Diagnostics, debugging, etc.
>>
>> 2) Supporting upgrades.
>>
> I completely disagree that the entire contents need to be preserved. And
> I don't see what a Keycloak upgrade has to do with anything.
>
>
>>
>>
>


-- 
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: myapp_sp_metadata.xml
Type: text/xml
Size: 3997 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160421/727fcb9f/attachment.xml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: myapp_sp_metadata_from_keycloak.xml
Type: text/xml
Size: 2180 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160421/727fcb9f/attachment-0001.xml 

From bburke at redhat.com  Fri Apr 22 09:56:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Apr 2016 09:56:10 -0400
Subject: [keycloak-dev] Keycloak's SAML AuthnResponse uses wrong binding
In-Reply-To: <57196A30.10600@redhat.com>
References: <57103C1C.8060806@redhat.com> <57119E66.6040005@redhat.com>
	<57124653.9090803@redhat.com> <571258FD.2090401@redhat.com>
	<571286EC.5080105@redhat.com> <57196A30.10600@redhat.com>
Message-ID: <571A2D7A.9050306@redhat.com>

John, to be honest, you can go on and on if you want, but I view this as 
a low priority and I don't agree with half of your assumptions and I 
just don't have the time to argue with you.  If you want to open some 
jira issues to describe in full your concrens feel free.  If you want to 
provide a patch even better, but we have a ton of more important issues 
in the queue that customers actually care about.  Not one person other 
than you has complained about how we handle importing SP metadata.  
We're a small team.  We have to prioritize resources.  Sorry.

On 4/21/2016 8:02 PM, John Dennis wrote:
> On 04/16/2016 02:39 PM, Bill Burke wrote:
>
> Sorry for the delay in responding, I was out on PTO.
>
>> On 4/16/2016 11:23 AM, John Dennis wrote:
>>> On 04/16/2016 10:04 AM, Bill Burke wrote:
>>>>>> I also noticed that when I used the Web UI to examine the SP 
>>>>>> metadata
>>>>>> (Installation tab of the realm client, selecting the "SAML Metadata
>>>>>> SPSSODescriptor" format) that it did not match the SP metadata that
>>>>>> had been loaded using the client registration service. Not only 
>>>>>> wasn't
>>>>>> it the exact same metadata, but specifically it was missing 
>>>>>> several of
>>>>>> the endpoints the SP declared in it's metadata. Why isn't the 
>>>>>> metadata
>>>>>> the same and why did Keycloak drop essential endpoint/binding
>>>>>> information?
>>>
>>>> Its not going to store the exact SP metadata file that was imported.
>>>> Keycloak only imports SP metadata that Keycloak.  Also, the admin
>>>> console is allowed to modify this imported metadata however it 
>>>> wants. I
>>>> don't see a problem with this behavior at all.
>>>
>>> Here is the issue. I'm an admin and I register my SP with Keycloak.
>>> But either because things are not working as expected or because I
>>> simply can't remember if I updated the SP metadata in the Keycloak IdP
>>> after I made a change in the SP at my end I decide to go the the
>>> Keycloak Web UI and check and see what Keycloak thinks my SP 
>>> metadata is.
>>>
>>> Instead of seeing what I believe my SP metadata should be I see
>>> something completely different and that is a red flag. I wonder why
>>> the metadata I load is not the same metadata Keycloak is operating on.
>>> Is this the source of my problems?
>>>
>>> In particular I'm concerned about Keycloak dropping my SP's SAML
>>> endpoints.
>>>
>>
>> I don't think your concern is valid or a red flag.
>
> Let me try to explain why an IdP modifying an SP's metadata is a concern.
>
> As an illustration of the problem I've attached the SP metadata I 
> loaded into Keycloak (myapp_sp_metadata.xml) and what Keycloak reports 
> as the SP's metadata when queried from the client installation tab in 
> the "SAML Metadata SPSSODescriptor" format. Here are where the 
> metadata differs between the actual SP metadata and Keycloak's version 
> of the SP metadata:
>
> 1) Keycloak has added a protocolSupportEnumeration for 
> urn:oasis:names:tc:SAML:1.1:protocol which the SP never reported 
> support for.
>
> 2) Keycloak has dropped the x509 encryption information.
>
> 3) Keycloak has dropped the SingleLogoutService using the 
> HTTP-Redirect binding.
>
> 4) Keycloak has dropped the AssertionConsumerService using the 
> HTTP-Artifact binding.
>
> 5) Keycloak has dropped the AssertionConsumerService using the PAOS 
> binding.
>

The metadata keycloak produces is the picture of what

> This is clearly not what the SP reported to the IdP and I continue to 
> believe this is a problem. IdP's are not permitted to alter the SP 
> configuration information, rather an IdP is supposed to use the SP 
> information verbatim (provided the IdP trusts the metadata).
>
> It is common practice in SAML for admins to examine metadata. Why? 
> Because most SAML problems are the result of incorrect metadata. When 
> things aren't working as expected the first course of action should be 
> to check the loaded metadata because the metadata drives the entire 
> relationship between entities. A mistake in the metadata will 
> certainly throw things into the weeds. Something not working? Check 
> the metadata! If the IdP reports metadata different than provided by 
> the SP then that absolutely will raise red flags.
>
>> Please correct me if
>> I'm wrong, but there is absolutely nothing within the SP metadata file
>> that defines the preferred way the client wants to communicate if there
>> are multiple options defined.
>
> Actually the SP does indicate it's default AssertionConsumerService, 
> it's desire for signed responses, encrypted responses, etc. in it's 
> metadata. The IdP is supposed to honor them if it's able.
>
>> Also, it is usually the IDP side that
>> drives these preferences, not the client.
>
> The IdP must respect what the SP reported.
>

It does respect what was reported, it ju

> Let me give another example. Some SAML bindings require the 
> Destination attribute. But if the IdP has thrown away the binding 
> endpoint for an SP how can it set the Destination attribute?
>
> Also the IdP is supposed to validate the AssertionConsumerServiceURL 
> against the value supplied in the SP metadata.
>
>>
>>> I think what you're implying is that Keycloak will parse the SP
>>> metadata and retain only those parts of it which it currently
>>> understands, it then stores the data it picked out of the metadata in
>>> persistent storage and when asked to display the metadata Keycloak
>>> will read it's internal datastore and format it as SAML metadata.
>>> Correct?
>>>
>>
>> No, it parses the SP metadata file and decides how it is going to
>> interact with the SP based on best practices, i.e. POST over 
>> Redirect, etc.
>>
>>> If so what happens when Keycloak grows support for other SAML
>>> features? Are you then going to require every SP to re-register
>>> themselves so that Keycloak can parse the metadata again and rebuild
>>> it's internal data structures? Shouldn't after a Keycloak upgrade
>>> things just work?
>>>
>> If it works before Keycloak is upgraded, why wouldn't it work after?
>
> It's not a question of features no longer working, but rather the 
> inability of new features to work after an upgrade without requiring 
> the all SP's to register once again so that Keycloak can read 
> information which is now necessary but was formerly discarded [1].
>
> Simple. Let's use encryption as an example. I'm guessing Keycloak does 
> not currently support receiving encrypted requests because Keycloak 
> has deleted the encryption information from the SP. Now lets say in a 
> later release Keycloak supports encrypted requests. How are you going 
> to decrypt the request if you didn't preserve the encryption 
> parameters the SP provided to you in it's metadata? Are you going to 
> require every SP to register themselves with Keycloak again? The same 
> holds true for other features.
>
> [1] I'm still working on the assumption Keycloak does not preserve the 
> SP metadata verbatim but rather parses it and stores processed data 
> instead. The SAML IdP's I'm most familiar with (Shibboleth V3 and 
> Ipsilon) store the metadata and parse the stored metadata each time an 
> entity is loaded. This allows them to accurately report the metadata 
> and respond to bug fixes and feature upgrades when a new software 
> version is installed because it's working from the canonical source 
> description of the entity (e.g. the metadata).
>
>> I really don't see the admin wanting to switch to Artifact if Keycloak
>> ever ends up supporting it.    Also, IMO, it is just as likely that the
>> admin defines the client in the admin console and exports the SP
>> metadata to be consumed by mod-auth-mellon, than for somebody to craft
>> an SP metadata file and import it into Keycloak.
>
> Keycloak should never be in the business of generating an SP's metadata.
>
> How can an IdP possibly know anything about an SP? IdP's cannot define 
> what an SP is or how it is configured. Suggesting an IdP can know a 
> prori how an SP is configured or what it's capabilities are is way 
> outside normal SAML practice and is fundamentally backwards. If IdP's 
> were capable of knowing enough about a SP such that it could generate 
> the SP's metadata then why would metadata exchange even exist? 
> Metadata and metadata exchange is a fundamental building block of SAML 
> with it's own specification and exists for a reason.
>
> Let me give a concrete example of why your suggestion that Keycloak 
> would generate the metadata for a mellon SP is flawed. Up until 
> recently mellon did not support ECP. ECP requires the SP export an 
> AssertionConsumerService with a PAOS binding. So how is Keycloak going 
> to generate the correct metadata for a mellon SP if it doesn't know 
> what the version of mellon is and the versions of the libraries that 
> mellon links with on the SP? Those are critical components of what 
> mellon's capabilities are. So how is Keycloak as an IdP which is 
> completely independent of an SP going to generate correct metadata? 
> It's completely backwards to normal SAML. IdP's don't generate SP 
> metadata, rather IdP's consume SP metadata. How is an IdP going to 
> know an SP's security requirements? (e.g. signed responses, encrypted 
> responses, validity period, etc.) How is an IdP going to know what the 
> default service endpoint is or the correct ordering of endpoints? 
> Don't forget that an SP may communicate with multiple IdP's thus the 
> SP metadata must be valid across a set of IdP's (the other IdP's will 
> be unknown to Keycloak).
>
>> It really depends if
>> the admin is migrating from an existing SSO solution to Keycloak or not.
>>
>> IMO, what the bug fixes should be are:
>> * Make sure "Force POST Binding" is on by default (High Priority)
>> * Don't support an import unless there are valid bindings.  i.e. if only
>> artifact is listed, then abort import with an error. (High priority)
>> * Add support for ACSI and ACSU (low priority)
>> * Add support for Artifact Binding (very low priority, to Won't 
>> Implement)
>>
>>
>>> So there are 2 reasons why the entire contents of original metadata
>>> should be preserved:
>>>
>>> 1) Diagnostics, debugging, etc.
>>>
>>> 2) Supporting upgrades.
>>>
>> I completely disagree that the entire contents need to be preserved. And
>> I don't see what a Keycloak upgrade has to do with anything.
>>
>>
>>>
>>>
>>
>
>

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


From 00hf11 at gmail.com  Fri Apr 22 10:06:24 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Fri, 22 Apr 2016 11:06:24 -0300
Subject: [keycloak-dev] Some questions about refresh tokens
Message-ID: <CABv=XZVfBYTzt-zf8UCo_B8DA=dtw8+ooRSdwyEidAaiZ6jMsA@mail.gmail.com>

Hi,

I'm trying to use this code to refresh a token :

https://github.com/keycloak/keycloak-nodejs-auth-utils/blob/master/lib/grant-manager.js#L207

Also noticed that endpoint changed ^

So after to read :

https://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html

I modified the url but I can not get a refreshed token

Also, following the example :

https://github.com/keycloak/keycloak/blob/5c98b8c6ae7052b2d906156d8fc212ccd9dfd57d/docbook/auth-server-docs/reference/en/en-US/modules/direct-access.xml#L71-L74

I noticed that access_token is the same as refresh_token.

Questions:

1. Still possible to refresh token ?
2. If yes, how to do it ? [url, parameters... or configuration on Keycloak
?]

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160422/9504461c/attachment.html 

From bburke at redhat.com  Fri Apr 22 11:45:55 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Apr 2016 11:45:55 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
Message-ID: <571A4733.7000606@redhat.com>

The add-user.sh script overwrites the one that comes distributed with 
Wildfly/EAP.  Is this intentional?  To set up domain mode on multiple 
servers you need to be able to add an admin user to the domain and share the
secret with slave hosts so they can connect to the domain controller.

Can I rename add-user.sh to something else?

keycloak-add-user.sh
  - or -
sso-add-user.sh
  - or -

????

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


From mposolda at redhat.com  Fri Apr 22 11:56:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 22 Apr 2016 17:56:40 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571A4733.7000606@redhat.com>
References: <571A4733.7000606@redhat.com>
Message-ID: <571A49B8.4040601@redhat.com>

AFAIK it is intentional on standalone keycloak server. If you use 
parameter "--container" it will delegate to the wildfly impl, so you 
have the possibility to add the "wildfly" admin. Not sure if this is 
properly documented...

With overlay, we don't overwrite the default wildfly "add-user.sh" but 
instead we add our own "add-user-keycloak.sh".

Marek


On 22/04/16 17:45, Bill Burke wrote:
> The add-user.sh script overwrites the one that comes distributed with
> Wildfly/EAP.  Is this intentional?  To set up domain mode on multiple
> servers you need to be able to add an admin user to the domain and share the
> secret with slave hosts so they can connect to the domain controller.
>
> Can I rename add-user.sh to something else?
>
> keycloak-add-user.sh
>    - or -
> sso-add-user.sh
>    - or -
>
> ????
>


From bburke at redhat.com  Fri Apr 22 13:32:09 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Apr 2016 13:32:09 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571A49B8.4040601@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
Message-ID: <571A6019.4000605@redhat.com>

I don't think we should do this.  We are going to need to leverage the 
JBoss EAP/Wildfly documentation on how to manage the server.  We can't 
be overriding commands that exist for JBoss.  There is going to be a lot 
of confusion.

On 4/22/2016 11:56 AM, Marek Posolda wrote:
> AFAIK it is intentional on standalone keycloak server. If you use 
> parameter "--container" it will delegate to the wildfly impl, so you 
> have the possibility to add the "wildfly" admin. Not sure if this is 
> properly documented...
>
> With overlay, we don't overwrite the default wildfly "add-user.sh" but 
> instead we add our own "add-user-keycloak.sh".
>
> Marek
>
>
> On 22/04/16 17:45, Bill Burke wrote:
>> The add-user.sh script overwrites the one that comes distributed with
>> Wildfly/EAP.  Is this intentional?  To set up domain mode on multiple
>> servers you need to be able to add an admin user to the domain and 
>> share the
>> secret with slave hosts so they can connect to the domain controller.
>>
>> Can I rename add-user.sh to something else?
>>
>> keycloak-add-user.sh
>>    - or -
>> sso-add-user.sh
>>    - or -
>>
>> ????
>>
>

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


From bburke at redhat.com  Fri Apr 22 14:43:09 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Apr 2016 14:43:09 -0400
Subject: [keycloak-dev] domain mode changes
Message-ID: <571A70BD.50300@redhat.com>

I'd like to make the following changes to domain.xml that we distribute 
so that it runs as a cluster with a load balance out of the box on one 
machine:

* remove the "default" profile.  Users should really only be using 
domain mode with a cluster
* remove host.xml.  Its confusing to have both a host.xml and a 
host-master.xml
* host-master.xml will boot only 1 server ("server-one")
* host-slave.xml will boot only 1 server ("server-two")
* Pre-configure a undertow load balancer [1] to loadbalance between 
server one and server two
* Point H2 to a shared directory under domain/servers

I've checked that this setup works on my laptop.  I hope to write a 
Getting Started Guide around this too.

[1] 
https://docs.jboss.org/author/display/WFLY10/Using+Wildfly+as+a+Load+Balancer

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


From mposolda at redhat.com  Fri Apr 22 15:57:01 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 22 Apr 2016 21:57:01 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571A6019.4000605@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com>
Message-ID: <571A820D.8050705@redhat.com>

That's the question...

For server distribution, we also have our stuff ( keycloak subsystem, 
datasource, infinispan etc) directly declared in "standalone.xml". On 
the other hand, for overlay distribution, we don't want to directly 
update default "standalone.xml", so we are adding our own 
"standalone-keycloak.xml". Isn't it quite similar thing?

We can do the same for overlay and server distribution, so never edit 
default wildfly files ( standalone.xml , add-user.sh), but always use 
our own versions with "-keycloak" suffix. Advantage is more consistent. 
However people will need to always start keycloak server with 
"./standalone.sh -c standalone-keycloak.xml" then. Doesn't it sucks from 
the usability perspective?

I honestly don't know what's the best way regarding usability. AFAIK 
this was decided on mailing lists couple of months ago, but don't 
remember the exact threads...:/

Marek



On 22/04/16 19:32, Bill Burke wrote:
> I don't think we should do this.  We are going to need to leverage the 
> JBoss EAP/Wildfly documentation on how to manage the server. We can't 
> be overriding commands that exist for JBoss.  There is going to be a 
> lot of confusion.
>
> On 4/22/2016 11:56 AM, Marek Posolda wrote:
>> AFAIK it is intentional on standalone keycloak server. If you use 
>> parameter "--container" it will delegate to the wildfly impl, so you 
>> have the possibility to add the "wildfly" admin. Not sure if this is 
>> properly documented...
>>
>> With overlay, we don't overwrite the default wildfly "add-user.sh" 
>> but instead we add our own "add-user-keycloak.sh".
>>
>> Marek
>>
>>
>> On 22/04/16 17:45, Bill Burke wrote:
>>> The add-user.sh script overwrites the one that comes distributed with
>>> Wildfly/EAP.  Is this intentional?  To set up domain mode on multiple
>>> servers you need to be able to add an admin user to the domain and 
>>> share the
>>> secret with slave hosts so they can connect to the domain controller.
>>>
>>> Can I rename add-user.sh to something else?
>>>
>>> keycloak-add-user.sh
>>>    - or -
>>> sso-add-user.sh
>>>    - or -
>>>
>>> ????
>>>
>>
>


From bburke at redhat.com  Fri Apr 22 16:13:51 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Apr 2016 16:13:51 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571A820D.8050705@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
Message-ID: <571A85FF.3040900@redhat.com>



On 4/22/2016 3:57 PM, Marek Posolda wrote:
> That's the question...
>
> For server distribution, we also have our stuff ( keycloak subsystem, 
> datasource, infinispan etc) directly declared in "standalone.xml". On 
> the other hand, for overlay distribution, we don't want to directly 
> update default "standalone.xml", so we are adding our own 
> "standalone-keycloak.xml". Isn't it quite similar thing?
>

Product will not have the overlay distribution.

> We can do the same for overlay and server distribution, so never edit 
> default wildfly files ( standalone.xml , add-user.sh), but always use 
> our own versions with "-keycloak" suffix. Advantage is more 
> consistent. However people will need to always start keycloak server 
> with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it 
> sucks from the usability perspective?
>

The overlay exists because we can't distribute EAP within community.    
Keycloak should be run as a separate server, so, IMO, -keycloak.xml 
files should go away and overwrite standalone.xml, standalone-ha.xml and 
domain.xml

> I honestly don't know what's the best way regarding usability. AFAIK 
> this was decided on mailing lists couple of months ago, but don't 
> remember the exact threads...:/
>

I'm pretty adamant about this.  There will be a huge amount of confusion 
if we don't make this separation.  Wildfly/JBoss and Keycloak are hard 
enough to configure as it is.


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


From sthorger at redhat.com  Sat Apr 23 01:29:58 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Sat, 23 Apr 2016 07:29:58 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571A85FF.3040900@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
Message-ID: <CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>

In the future we need to secure the underlying WildFly with rhsso. In which
case our add-user will add users for both Keycloak and WildFly/EAP.

IMO there's going to be confusion until the above is solved no matter what
we do. We'll need to document this whichever way we do it. Options are stay
with what we have or rename our script. My vote goes to keep as is and
document it. Then hopefully by 7.1 we can secure the WildFly bits so the
problem goes away. With the other option (rename ours) there will be a
problem once WildFly bits are secured by Keycloak as now the wf add-user
script should no longer be used and completely removed at which point we
should then rename it back. So in the long run sticking with how it is
today is ideal. It's also way to late making changes now. BTW this has been
around for months.
On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com> wrote:

>
>
> On 4/22/2016 3:57 PM, Marek Posolda wrote:
> > That's the question...
> >
> > For server distribution, we also have our stuff ( keycloak subsystem,
> > datasource, infinispan etc) directly declared in "standalone.xml". On
> > the other hand, for overlay distribution, we don't want to directly
> > update default "standalone.xml", so we are adding our own
> > "standalone-keycloak.xml". Isn't it quite similar thing?
> >
>
> Product will not have the overlay distribution.
>
> > We can do the same for overlay and server distribution, so never edit
> > default wildfly files ( standalone.xml , add-user.sh), but always use
> > our own versions with "-keycloak" suffix. Advantage is more
> > consistent. However people will need to always start keycloak server
> > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it
> > sucks from the usability perspective?
> >
>
> The overlay exists because we can't distribute EAP within community.
> Keycloak should be run as a separate server, so, IMO, -keycloak.xml
> files should go away and overwrite standalone.xml, standalone-ha.xml and
> domain.xml
>
> > I honestly don't know what's the best way regarding usability. AFAIK
> > this was decided on mailing lists couple of months ago, but don't
> > remember the exact threads...:/
> >
>
> I'm pretty adamant about this.  There will be a huge amount of confusion
> if we don't make this separation.  Wildfly/JBoss and Keycloak are hard
> enough to configure as it is.
>
>
> --
> 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/20160423/3eb86989/attachment-0001.html 

From sthorger at redhat.com  Sat Apr 23 01:31:53 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Sat, 23 Apr 2016 07:31:53 +0200
Subject: [keycloak-dev] domain mode changes
In-Reply-To: <571A70BD.50300@redhat.com>
References: <571A70BD.50300@redhat.com>
Message-ID: <CAJgngAc9d6vs3kipgODmrBrP_iZZvVadn4wsvXW0nbuM=j9frQ@mail.gmail.com>

I vote against this. It's way to late to start making changes unless
absolutely critical. At the moment we're just doing what WildFly/EAP does
out of the box and I don't see any need for us to do different to them.
On 22 Apr 2016 20:43, "Bill Burke" <bburke at redhat.com> wrote:

> I'd like to make the following changes to domain.xml that we distribute
> so that it runs as a cluster with a load balance out of the box on one
> machine:
>
> * remove the "default" profile.  Users should really only be using
> domain mode with a cluster
> * remove host.xml.  Its confusing to have both a host.xml and a
> host-master.xml
> * host-master.xml will boot only 1 server ("server-one")
> * host-slave.xml will boot only 1 server ("server-two")
> * Pre-configure a undertow load balancer [1] to loadbalance between
> server one and server two
> * Point H2 to a shared directory under domain/servers
>
> I've checked that this setup works on my laptop.  I hope to write a
> Getting Started Guide around this too.
>
> [1]
>
> https://docs.jboss.org/author/display/WFLY10/Using+Wildfly+as+a+Load+Balancer
>
> --
> 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/20160423/12fa3d42/attachment.html 

From bburke at redhat.com  Sat Apr 23 08:48:15 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 23 Apr 2016 08:48:15 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
Message-ID: <571B6F0F.6030702@redhat.com>

Do you care about usability at all?  Not everything can fit into nice 
little boxes all the time.  This is going to be extremely confusing for 
users.  I ran into it myself as I thought the jboss add-user.sh script 
was overwritten by our distribution script by mistake.  *OF COURSE* we 
should have a separate add-user.sh script. Even when, hopefully, JBoss 
can delegate to Keycloak in maybe 7.1. If we are going to leverage the 
JBoss platform, and this means the JBoss documentation too, every 
management function that exists in JBoss should be available in Keycloak 
and *WORK THE SAME WAY*.  If we don't change this, we're going to get a 
ton of support questions that say: "Why doesn't add-user.sh work?"



On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>
> In the future we need to secure the underlying WildFly with rhsso. In 
> which case our add-user will add users for both Keycloak and WildFly/EAP.
>
> IMO there's going to be confusion until the above is solved no matter 
> what we do. We'll need to document this whichever way we do it. 
> Options are stay with what we have or rename our script. My vote goes 
> to keep as is and document it. Then hopefully by 7.1 we can secure the 
> WildFly bits so the problem goes away. With the other option (rename 
> ours) there will be a problem once WildFly bits are secured by 
> Keycloak as now the wf add-user script should no longer be used and 
> completely removed at which point we should then rename it back. So in 
> the long run sticking with how it is today is ideal. It's also way to 
> late making changes now. BTW this has been around for months.
>
> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 4/22/2016 3:57 PM, Marek Posolda wrote:
>     > That's the question...
>     >
>     > For server distribution, we also have our stuff ( keycloak
>     subsystem,
>     > datasource, infinispan etc) directly declared in
>     "standalone.xml". On
>     > the other hand, for overlay distribution, we don't want to directly
>     > update default "standalone.xml", so we are adding our own
>     > "standalone-keycloak.xml". Isn't it quite similar thing?
>     >
>
>     Product will not have the overlay distribution.
>
>     > We can do the same for overlay and server distribution, so never
>     edit
>     > default wildfly files ( standalone.xml , add-user.sh), but
>     always use
>     > our own versions with "-keycloak" suffix. Advantage is more
>     > consistent. However people will need to always start keycloak server
>     > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it
>     > sucks from the usability perspective?
>     >
>
>     The overlay exists because we can't distribute EAP within community.
>     Keycloak should be run as a separate server, so, IMO, -keycloak.xml
>     files should go away and overwrite standalone.xml,
>     standalone-ha.xml and
>     domain.xml
>
>     > I honestly don't know what's the best way regarding usability. AFAIK
>     > this was decided on mailing lists couple of months ago, but don't
>     > remember the exact threads...:/
>     >
>
>     I'm pretty adamant about this.  There will be a huge amount of
>     confusion
>     if we don't make this separation.  Wildfly/JBoss and Keycloak are hard
>     enough to configure as it is.
>
>
>     --
>     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
>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160423/503bcb77/attachment.html 

From bburke at redhat.com  Sat Apr 23 08:52:44 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 23 Apr 2016 08:52:44 -0400
Subject: [keycloak-dev] domain mode changes
In-Reply-To: <CAJgngAc9d6vs3kipgODmrBrP_iZZvVadn4wsvXW0nbuM=j9frQ@mail.gmail.com>
References: <571A70BD.50300@redhat.com>
	<CAJgngAc9d6vs3kipgODmrBrP_iZZvVadn4wsvXW0nbuM=j9frQ@mail.gmail.com>
Message-ID: <571B701C.5030202@redhat.com>

This helps out with documenting domain mode to have an almost working 
example that I can walk through and explain.  The current distribution 
doesn't really help with that.  There's going to be more of this stuff.  
This is why I wanted to start on documentation in January as I knew 
little usability things like this would pop up.  So, deal with it...

Honestly, I should have just done this as I knew you were going to be a 
pain in the ass...

On 4/23/2016 1:31 AM, Stian Thorgersen wrote:
>
> I vote against this. It's way to late to start making changes unless 
> absolutely critical. At the moment we're just doing what WildFly/EAP 
> does out of the box and I don't see any need for us to do different to 
> them.
>
> On 22 Apr 2016 20:43, "Bill Burke" <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I'd like to make the following changes to domain.xml that we
>     distribute
>     so that it runs as a cluster with a load balance out of the box on one
>     machine:
>
>     * remove the "default" profile.  Users should really only be using
>     domain mode with a cluster
>     * remove host.xml.  Its confusing to have both a host.xml and a
>     host-master.xml
>     * host-master.xml will boot only 1 server ("server-one")
>     * host-slave.xml will boot only 1 server ("server-two")
>     * Pre-configure a undertow load balancer [1] to loadbalance between
>     server one and server two
>     * Point H2 to a shared directory under domain/servers
>
>     I've checked that this setup works on my laptop.  I hope to write a
>     Getting Started Guide around this too.
>
>     [1]
>     https://docs.jboss.org/author/display/WFLY10/Using+Wildfly+as+a+Load+Balancer
>
>     --
>     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
>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160423/668bdf35/attachment.html 

From irum at redhat.com  Sat Apr 23 09:06:59 2016
From: irum at redhat.com (Ilya Rum)
Date: Sat, 23 Apr 2016 15:06:59 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571B6F0F.6030702@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com>
Message-ID: <20160423130659.GA5385@wv-toplap>

Hello!

As a new member of keycloak QA team I recently had to set up some
clustering with domain mode.
I was really confused when add-user.sh did not add user to jboss but
rather created the keycloak-add-user.json.
The worst thing was that I couldn't find any docs on adding user to
underlying eap at all.
Had to read the add-user.sh itself to find out what was happening.
Even if it remains as it is, it really should be at least mentioned in
the docs :)

Have a nice day!
Ilya Rum.

On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
> Do you care about usability at all?  Not everything can fit into nice little
> boxes all the time.  This is going to be extremely confusing for users.  I
> ran into it myself as I thought the jboss add-user.sh script was overwritten
> by our distribution script by mistake.  *OF COURSE* we should have a
> separate add-user.sh script. Even when, hopefully, JBoss can delegate to
> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and
> this means the JBoss documentation too, every management function that
> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*.  If
> we don't change this, we're going to get a ton of support questions that
> say: "Why doesn't add-user.sh work?"
> 
> 
> 
> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
> >
> >In the future we need to secure the underlying WildFly with rhsso. In
> >which case our add-user will add users for both Keycloak and WildFly/EAP.
> >
> >IMO there's going to be confusion until the above is solved no matter what
> >we do. We'll need to document this whichever way we do it. Options are
> >stay with what we have or rename our script. My vote goes to keep as is
> >and document it. Then hopefully by 7.1 we can secure the WildFly bits so
> >the problem goes away. With the other option (rename ours) there will be a
> >problem once WildFly bits are secured by Keycloak as now the wf add-user
> >script should no longer be used and completely removed at which point we
> >should then rename it back. So in the long run sticking with how it is
> >today is ideal. It's also way to late making changes now. BTW this has
> >been around for months.
> >
> >On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
> ><mailto:bburke at redhat.com>> wrote:
> >
> >
> >
> >    On 4/22/2016 3:57 PM, Marek Posolda wrote:
> >    > That's the question...
> >    >
> >    > For server distribution, we also have our stuff ( keycloak
> >    subsystem,
> >    > datasource, infinispan etc) directly declared in
> >    "standalone.xml". On
> >    > the other hand, for overlay distribution, we don't want to directly
> >    > update default "standalone.xml", so we are adding our own
> >    > "standalone-keycloak.xml". Isn't it quite similar thing?
> >    >
> >
> >    Product will not have the overlay distribution.
> >
> >    > We can do the same for overlay and server distribution, so never
> >    edit
> >    > default wildfly files ( standalone.xml , add-user.sh), but
> >    always use
> >    > our own versions with "-keycloak" suffix. Advantage is more
> >    > consistent. However people will need to always start keycloak server
> >    > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it
> >    > sucks from the usability perspective?
> >    >
> >
> >    The overlay exists because we can't distribute EAP within community.
> >    Keycloak should be run as a separate server, so, IMO, -keycloak.xml
> >    files should go away and overwrite standalone.xml,
> >    standalone-ha.xml and
> >    domain.xml
> >
> >    > I honestly don't know what's the best way regarding usability. AFAIK
> >    > this was decided on mailing lists couple of months ago, but don't
> >    > remember the exact threads...:/
> >    >
> >
> >    I'm pretty adamant about this.  There will be a huge amount of
> >    confusion
> >    if we don't make this separation.  Wildfly/JBoss and Keycloak are hard
> >    enough to configure as it is.
> >
> >
> >    --
> >    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
> >
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

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


From ssilvert at redhat.com  Sat Apr 23 15:04:18 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Sat, 23 Apr 2016 15:04:18 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <20160423130659.GA5385@wv-toplap>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
Message-ID: <571BC732.7030108@redhat.com>

We had the same kind of problem in WildFly a few years ago.  Everyone 
was used to starting the server with run.sh.  But we needed to change 
that to differentiate between standalone.sh and domain.sh.  So we made 
run.bat just print out a "This is deprecated.  Here is what you need to 
do...." message.

It's not a perfect solution, but we could do the same thing with 
add-user.sh and tell them to use either add-user-keycloak.sh or 
add-user-eap.sh.  At least you wouldn't get any support questions.

On 4/23/2016 9:06 AM, Ilya Rum wrote:
> Hello!
>
> As a new member of keycloak QA team I recently had to set up some
> clustering with domain mode.
> I was really confused when add-user.sh did not add user to jboss but
> rather created the keycloak-add-user.json.
> The worst thing was that I couldn't find any docs on adding user to
> underlying eap at all.
> Had to read the add-user.sh itself to find out what was happening.
> Even if it remains as it is, it really should be at least mentioned in
> the docs :)
>
> Have a nice day!
> Ilya Rum.
>
> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>> Do you care about usability at all?  Not everything can fit into nice little
>> boxes all the time.  This is going to be extremely confusing for users.  I
>> ran into it myself as I thought the jboss add-user.sh script was overwritten
>> by our distribution script by mistake.  *OF COURSE* we should have a
>> separate add-user.sh script. Even when, hopefully, JBoss can delegate to
>> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and
>> this means the JBoss documentation too, every management function that
>> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*.  If
>> we don't change this, we're going to get a ton of support questions that
>> say: "Why doesn't add-user.sh work?"
>>
>>
>>
>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>> In the future we need to secure the underlying WildFly with rhsso. In
>>> which case our add-user will add users for both Keycloak and WildFly/EAP.
>>>
>>> IMO there's going to be confusion until the above is solved no matter what
>>> we do. We'll need to document this whichever way we do it. Options are
>>> stay with what we have or rename our script. My vote goes to keep as is
>>> and document it. Then hopefully by 7.1 we can secure the WildFly bits so
>>> the problem goes away. With the other option (rename ours) there will be a
>>> problem once WildFly bits are secured by Keycloak as now the wf add-user
>>> script should no longer be used and completely removed at which point we
>>> should then rename it back. So in the long run sticking with how it is
>>> today is ideal. It's also way to late making changes now. BTW this has
>>> been around for months.
>>>
>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>>> <mailto:bburke at redhat.com>> wrote:
>>>
>>>
>>>
>>>     On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>>     > That's the question...
>>>     >
>>>     > For server distribution, we also have our stuff ( keycloak
>>>     subsystem,
>>>     > datasource, infinispan etc) directly declared in
>>>     "standalone.xml". On
>>>     > the other hand, for overlay distribution, we don't want to directly
>>>     > update default "standalone.xml", so we are adding our own
>>>     > "standalone-keycloak.xml". Isn't it quite similar thing?
>>>     >
>>>
>>>     Product will not have the overlay distribution.
>>>
>>>     > We can do the same for overlay and server distribution, so never
>>>     edit
>>>     > default wildfly files ( standalone.xml , add-user.sh), but
>>>     always use
>>>     > our own versions with "-keycloak" suffix. Advantage is more
>>>     > consistent. However people will need to always start keycloak server
>>>     > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it
>>>     > sucks from the usability perspective?
>>>     >
>>>
>>>     The overlay exists because we can't distribute EAP within community.
>>>     Keycloak should be run as a separate server, so, IMO, -keycloak.xml
>>>     files should go away and overwrite standalone.xml,
>>>     standalone-ha.xml and
>>>     domain.xml
>>>
>>>     > I honestly don't know what's the best way regarding usability. AFAIK
>>>     > this was decided on mailing lists couple of months ago, but don't
>>>     > remember the exact threads...:/
>>>     >
>>>
>>>     I'm pretty adamant about this.  There will be a huge amount of
>>>     confusion
>>>     if we don't make this separation.  Wildfly/JBoss and Keycloak are hard
>>>     enough to configure as it is.
>>>
>>>
>>>     --
>>>     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
>>>
>> -- 
>> 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  Sun Apr 24 13:50:08 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Sun, 24 Apr 2016 19:50:08 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571BC732.7030108@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com>
Message-ID: <571D0750.5030202@redhat.com>

Maybe we can keep as is, but always when people run "add-user.sh" there 
will be big warning like "You are adding Keycloak admin, but not Wildfly 
admin!!! if you want to add Wildfly admin use the option --container".

We can remove this in the future though, once adding keycloak admin and 
wildfly admin is going to be same thing.

Marek

On 23/04/16 21:04, Stan Silvert wrote:
> We had the same kind of problem in WildFly a few years ago.  Everyone
> was used to starting the server with run.sh.  But we needed to change
> that to differentiate between standalone.sh and domain.sh.  So we made
> run.bat just print out a "This is deprecated.  Here is what you need to
> do...." message.
>
> It's not a perfect solution, but we could do the same thing with
> add-user.sh and tell them to use either add-user-keycloak.sh or
> add-user-eap.sh.  At least you wouldn't get any support questions.
>
> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>> Hello!
>>
>> As a new member of keycloak QA team I recently had to set up some
>> clustering with domain mode.
>> I was really confused when add-user.sh did not add user to jboss but
>> rather created the keycloak-add-user.json.
>> The worst thing was that I couldn't find any docs on adding user to
>> underlying eap at all.
>> Had to read the add-user.sh itself to find out what was happening.
>> Even if it remains as it is, it really should be at least mentioned in
>> the docs :)
>>
>> Have a nice day!
>> Ilya Rum.
>>
>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>>> Do you care about usability at all?  Not everything can fit into nice little
>>> boxes all the time.  This is going to be extremely confusing for users.  I
>>> ran into it myself as I thought the jboss add-user.sh script was overwritten
>>> by our distribution script by mistake.  *OF COURSE* we should have a
>>> separate add-user.sh script. Even when, hopefully, JBoss can delegate to
>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and
>>> this means the JBoss documentation too, every management function that
>>> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*.  If
>>> we don't change this, we're going to get a ton of support questions that
>>> say: "Why doesn't add-user.sh work?"
>>>
>>>
>>>
>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>>> In the future we need to secure the underlying WildFly with rhsso. In
>>>> which case our add-user will add users for both Keycloak and WildFly/EAP.
>>>>
>>>> IMO there's going to be confusion until the above is solved no matter what
>>>> we do. We'll need to document this whichever way we do it. Options are
>>>> stay with what we have or rename our script. My vote goes to keep as is
>>>> and document it. Then hopefully by 7.1 we can secure the WildFly bits so
>>>> the problem goes away. With the other option (rename ours) there will be a
>>>> problem once WildFly bits are secured by Keycloak as now the wf add-user
>>>> script should no longer be used and completely removed at which point we
>>>> should then rename it back. So in the long run sticking with how it is
>>>> today is ideal. It's also way to late making changes now. BTW this has
>>>> been around for months.
>>>>
>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>>>> <mailto:bburke at redhat.com>> wrote:
>>>>
>>>>
>>>>
>>>>      On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>>>      > That's the question...
>>>>      >
>>>>      > For server distribution, we also have our stuff ( keycloak
>>>>      subsystem,
>>>>      > datasource, infinispan etc) directly declared in
>>>>      "standalone.xml". On
>>>>      > the other hand, for overlay distribution, we don't want to directly
>>>>      > update default "standalone.xml", so we are adding our own
>>>>      > "standalone-keycloak.xml". Isn't it quite similar thing?
>>>>      >
>>>>
>>>>      Product will not have the overlay distribution.
>>>>
>>>>      > We can do the same for overlay and server distribution, so never
>>>>      edit
>>>>      > default wildfly files ( standalone.xml , add-user.sh), but
>>>>      always use
>>>>      > our own versions with "-keycloak" suffix. Advantage is more
>>>>      > consistent. However people will need to always start keycloak server
>>>>      > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it
>>>>      > sucks from the usability perspective?
>>>>      >
>>>>
>>>>      The overlay exists because we can't distribute EAP within community.
>>>>      Keycloak should be run as a separate server, so, IMO, -keycloak.xml
>>>>      files should go away and overwrite standalone.xml,
>>>>      standalone-ha.xml and
>>>>      domain.xml
>>>>
>>>>      > I honestly don't know what's the best way regarding usability. AFAIK
>>>>      > this was decided on mailing lists couple of months ago, but don't
>>>>      > remember the exact threads...:/
>>>>      >
>>>>
>>>>      I'm pretty adamant about this.  There will be a huge amount of
>>>>      confusion
>>>>      if we don't make this separation.  Wildfly/JBoss and Keycloak are hard
>>>>      enough to configure as it is.
>>>>
>>>>
>>>>      --
>>>>      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
>>>>
>>> -- 
>>> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Sun Apr 24 13:56:16 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Sun, 24 Apr 2016 19:56:16 +0200
Subject: [keycloak-dev] domain mode changes
In-Reply-To: <571B701C.5030202@redhat.com>
References: <571A70BD.50300@redhat.com>
	<CAJgngAc9d6vs3kipgODmrBrP_iZZvVadn4wsvXW0nbuM=j9frQ@mail.gmail.com>
	<571B701C.5030202@redhat.com>
Message-ID: <571D08C0.2040508@redhat.com>

Do you think that people will use cluster with 2 nodes on localhost + 
embedded H2 + static loadbalancer in production? I guess not. So having 
our domain.xml "pre-set" to have easy example cluster setup won't help 
much IMO. Customers will be able to setup "easy" cluster in 5 minutes, 
but they will be unaware of all the steps they need to set the real 
"production" cluster.

Also there is inconsistency with Wildfly, which may lead to some other 
confusions (as you pointed in other thread for add-user script).

I think that what would be helpful is, to guide people through all the 
manual steps more deeply, so after "absolve" the tutorial, they will be 
able to set the domain with real production cluster in their environment 
with 2 remote nodes on different machines communicate between each 
other. And they will know the possibilities for setup real loadbalancer 
too (HTTPD+modcluster or Undertow+modcluster etc). But I am not sure how 
deep to go there, as loadbalancer is not directly our stuff...

Also maybe it would be helpful to have some guides for setup AWS or 
JGroups without Multicast, but with TCP and TCPPING. I know it's not our 
stuff, but you know... There were gazillion questions regarding this in 
last months ;-)

Marek

On 23/04/16 14:52, Bill Burke wrote:
> This helps out with documenting domain mode to have an almost working 
> example that I can walk through and explain.  The current distribution 
> doesn't really help with that.  There's going to be more of this 
> stuff.  This is why I wanted to start on documentation in January as I 
> knew little usability things like this would pop up.  So, deal with it...
>
> Honestly, I should have just done this as I knew you were going to be 
> a pain in the ass...
>
> On 4/23/2016 1:31 AM, Stian Thorgersen wrote:
>>
>> I vote against this. It's way to late to start making changes unless 
>> absolutely critical. At the moment we're just doing what WildFly/EAP 
>> does out of the box and I don't see any need for us to do different 
>> to them.
>>
>> On 22 Apr 2016 20:43, "Bill Burke" <bburke at redhat.com> wrote:
>>
>>     I'd like to make the following changes to domain.xml that we
>>     distribute
>>     so that it runs as a cluster with a load balance out of the box
>>     on one
>>     machine:
>>
>>     * remove the "default" profile.  Users should really only be using
>>     domain mode with a cluster
>>     * remove host.xml.  Its confusing to have both a host.xml and a
>>     host-master.xml
>>     * host-master.xml will boot only 1 server ("server-one")
>>     * host-slave.xml will boot only 1 server ("server-two")
>>     * Pre-configure a undertow load balancer [1] to loadbalance between
>>     server one and server two
>>     * Point H2 to a shared directory under domain/servers
>>
>>     I've checked that this setup works on my laptop.  I hope to write a
>>     Getting Started Guide around this too.
>>
>>     [1]
>>     https://docs.jboss.org/author/display/WFLY10/Using+Wildfly+as+a+Load+Balancer
>>
>>     --
>>     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
>>
>
> -- 
> 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/20160424/53646013/attachment.html 

From bburke at redhat.com  Sun Apr 24 14:47:26 2016
From: bburke at redhat.com (Bill Burke)
Date: Sun, 24 Apr 2016 14:47:26 -0400
Subject: [keycloak-dev] domain mode changes
In-Reply-To: <571D08C0.2040508@redhat.com>
References: <571A70BD.50300@redhat.com>
	<CAJgngAc9d6vs3kipgODmrBrP_iZZvVadn4wsvXW0nbuM=j9frQ@mail.gmail.com>
	<571B701C.5030202@redhat.com> <571D08C0.2040508@redhat.com>
Message-ID: <571D14BE.9040701@redhat.com>



On 4/24/2016 1:56 PM, Marek Posolda wrote:
> Do you think that people will use cluster with 2 nodes on localhost + 
> embedded H2 + static loadbalancer in production? I guess not. So 
> having our domain.xml "pre-set" to have easy example cluster setup 
> won't help much IMO. Customers will be able to setup "easy" cluster in 
> 5 minutes, but they will be unaware of all the steps they need to set 
> the real "production" cluster.
>

I honestly don't see what the big deal is.  The current default domain 
setup won't work in a cluster either.

I'm changing it... and that's that....It allows me to walk through an 
out-of-the-box example that can run on somebody's laptop.  If either you 
are Stian want to change it back, then you can rewrite the domain 
section of the install guide.

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

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

From bburke at redhat.com  Sun Apr 24 14:55:46 2016
From: bburke at redhat.com (Bill Burke)
Date: Sun, 24 Apr 2016 14:55:46 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571D0750.5030202@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com> <571D0750.5030202@redhat.com>
Message-ID: <571D16B2.3010607@redhat.com>

I still 100% disagree.  I'm changing it.  You guys can feel free to 
change it back, but you can also feel free to

a) read the keycloak docs and document everywhere we need the wildfly 
add-user.sh script
b) Answer any and all support questions on the problem

In the future the add-user.sh script can just be removed and people can 
keep using the keycloak-add-user.sh script, or better yet, integrate 
keycloak-add-user with the jboss-cli.

On 4/24/2016 1:50 PM, Marek Posolda wrote:
> Maybe we can keep as is, but always when people run "add-user.sh" there
> will be big warning like "You are adding Keycloak admin, but not Wildfly
> admin!!! if you want to add Wildfly admin use the option --container".
>
> We can remove this in the future though, once adding keycloak admin and
> wildfly admin is going to be same thing.
>
> Marek
>
> On 23/04/16 21:04, Stan Silvert wrote:
>> We had the same kind of problem in WildFly a few years ago.  Everyone
>> was used to starting the server with run.sh.  But we needed to change
>> that to differentiate between standalone.sh and domain.sh.  So we made
>> run.bat just print out a "This is deprecated.  Here is what you need to
>> do...." message.
>>
>> It's not a perfect solution, but we could do the same thing with
>> add-user.sh and tell them to use either add-user-keycloak.sh or
>> add-user-eap.sh.  At least you wouldn't get any support questions.
>>
>> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>>> Hello!
>>>
>>> As a new member of keycloak QA team I recently had to set up some
>>> clustering with domain mode.
>>> I was really confused when add-user.sh did not add user to jboss but
>>> rather created the keycloak-add-user.json.
>>> The worst thing was that I couldn't find any docs on adding user to
>>> underlying eap at all.
>>> Had to read the add-user.sh itself to find out what was happening.
>>> Even if it remains as it is, it really should be at least mentioned in
>>> the docs :)
>>>
>>> Have a nice day!
>>> Ilya Rum.
>>>
>>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>>>> Do you care about usability at all?  Not everything can fit into nice little
>>>> boxes all the time.  This is going to be extremely confusing for users.  I
>>>> ran into it myself as I thought the jboss add-user.sh script was overwritten
>>>> by our distribution script by mistake.  *OF COURSE* we should have a
>>>> separate add-user.sh script. Even when, hopefully, JBoss can delegate to
>>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and
>>>> this means the JBoss documentation too, every management function that
>>>> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*.  If
>>>> we don't change this, we're going to get a ton of support questions that
>>>> say: "Why doesn't add-user.sh work?"
>>>>
>>>>
>>>>
>>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>>>> In the future we need to secure the underlying WildFly with rhsso. In
>>>>> which case our add-user will add users for both Keycloak and WildFly/EAP.
>>>>>
>>>>> IMO there's going to be confusion until the above is solved no matter what
>>>>> we do. We'll need to document this whichever way we do it. Options are
>>>>> stay with what we have or rename our script. My vote goes to keep as is
>>>>> and document it. Then hopefully by 7.1 we can secure the WildFly bits so
>>>>> the problem goes away. With the other option (rename ours) there will be a
>>>>> problem once WildFly bits are secured by Keycloak as now the wf add-user
>>>>> script should no longer be used and completely removed at which point we
>>>>> should then rename it back. So in the long run sticking with how it is
>>>>> today is ideal. It's also way to late making changes now. BTW this has
>>>>> been around for months.
>>>>>
>>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>>>>> <mailto:bburke at redhat.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>       On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>>>>       > That's the question...
>>>>>       >
>>>>>       > For server distribution, we also have our stuff ( keycloak
>>>>>       subsystem,
>>>>>       > datasource, infinispan etc) directly declared in
>>>>>       "standalone.xml". On
>>>>>       > the other hand, for overlay distribution, we don't want to directly
>>>>>       > update default "standalone.xml", so we are adding our own
>>>>>       > "standalone-keycloak.xml". Isn't it quite similar thing?
>>>>>       >
>>>>>
>>>>>       Product will not have the overlay distribution.
>>>>>
>>>>>       > We can do the same for overlay and server distribution, so never
>>>>>       edit
>>>>>       > default wildfly files ( standalone.xml , add-user.sh), but
>>>>>       always use
>>>>>       > our own versions with "-keycloak" suffix. Advantage is more
>>>>>       > consistent. However people will need to always start keycloak server
>>>>>       > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it
>>>>>       > sucks from the usability perspective?
>>>>>       >
>>>>>
>>>>>       The overlay exists because we can't distribute EAP within community.
>>>>>       Keycloak should be run as a separate server, so, IMO, -keycloak.xml
>>>>>       files should go away and overwrite standalone.xml,
>>>>>       standalone-ha.xml and
>>>>>       domain.xml
>>>>>
>>>>>       > I honestly don't know what's the best way regarding usability. AFAIK
>>>>>       > this was decided on mailing lists couple of months ago, but don't
>>>>>       > remember the exact threads...:/
>>>>>       >
>>>>>
>>>>>       I'm pretty adamant about this.  There will be a huge amount of
>>>>>       confusion
>>>>>       if we don't make this separation.  Wildfly/JBoss and Keycloak are hard
>>>>>       enough to configure as it is.
>>>>>
>>>>>
>>>>>       --
>>>>>       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
>>>>>
>>>> -- 
>>>> 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
>> _______________________________________________
>> 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  Sun Apr 24 14:58:57 2016
From: bburke at redhat.com (Bill Burke)
Date: Sun, 24 Apr 2016 14:58:57 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571BC732.7030108@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com>
Message-ID: <571D1771.3020405@redhat.com>

Completely different.  standalone.sh and domain.sh are completely new 
run.sh variants and run.sh disappeared.

add-user.sh is the same script as the old.  and you've already had two 
Red Hat people scratching their heads wondering what happened to 
add-user.sh.

On 4/23/2016 3:04 PM, Stan Silvert wrote:
> We had the same kind of problem in WildFly a few years ago.  Everyone
> was used to starting the server with run.sh.  But we needed to change
> that to differentiate between standalone.sh and domain.sh.  So we made
> run.bat just print out a "This is deprecated.  Here is what you need to
> do...." message.
>
> It's not a perfect solution, but we could do the same thing with
> add-user.sh and tell them to use either add-user-keycloak.sh or
> add-user-eap.sh.  At least you wouldn't get any support questions.
>
> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>> Hello!
>>
>> As a new member of keycloak QA team I recently had to set up some
>> clustering with domain mode.
>> I was really confused when add-user.sh did not add user to jboss but
>> rather created the keycloak-add-user.json.
>> The worst thing was that I couldn't find any docs on adding user to
>> underlying eap at all.
>> Had to read the add-user.sh itself to find out what was happening.
>> Even if it remains as it is, it really should be at least mentioned in
>> the docs :)
>>
>> Have a nice day!
>> Ilya Rum.
>>
>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>>> Do you care about usability at all?  Not everything can fit into nice little
>>> boxes all the time.  This is going to be extremely confusing for users.  I
>>> ran into it myself as I thought the jboss add-user.sh script was overwritten
>>> by our distribution script by mistake.  *OF COURSE* we should have a
>>> separate add-user.sh script. Even when, hopefully, JBoss can delegate to
>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and
>>> this means the JBoss documentation too, every management function that
>>> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*.  If
>>> we don't change this, we're going to get a ton of support questions that
>>> say: "Why doesn't add-user.sh work?"
>>>
>>>
>>>
>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>>> In the future we need to secure the underlying WildFly with rhsso. In
>>>> which case our add-user will add users for both Keycloak and WildFly/EAP.
>>>>
>>>> IMO there's going to be confusion until the above is solved no matter what
>>>> we do. We'll need to document this whichever way we do it. Options are
>>>> stay with what we have or rename our script. My vote goes to keep as is
>>>> and document it. Then hopefully by 7.1 we can secure the WildFly bits so
>>>> the problem goes away. With the other option (rename ours) there will be a
>>>> problem once WildFly bits are secured by Keycloak as now the wf add-user
>>>> script should no longer be used and completely removed at which point we
>>>> should then rename it back. So in the long run sticking with how it is
>>>> today is ideal. It's also way to late making changes now. BTW this has
>>>> been around for months.
>>>>
>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>>>> <mailto:bburke at redhat.com>> wrote:
>>>>
>>>>
>>>>
>>>>      On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>>>      > That's the question...
>>>>      >
>>>>      > For server distribution, we also have our stuff ( keycloak
>>>>      subsystem,
>>>>      > datasource, infinispan etc) directly declared in
>>>>      "standalone.xml". On
>>>>      > the other hand, for overlay distribution, we don't want to directly
>>>>      > update default "standalone.xml", so we are adding our own
>>>>      > "standalone-keycloak.xml". Isn't it quite similar thing?
>>>>      >
>>>>
>>>>      Product will not have the overlay distribution.
>>>>
>>>>      > We can do the same for overlay and server distribution, so never
>>>>      edit
>>>>      > default wildfly files ( standalone.xml , add-user.sh), but
>>>>      always use
>>>>      > our own versions with "-keycloak" suffix. Advantage is more
>>>>      > consistent. However people will need to always start keycloak server
>>>>      > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it
>>>>      > sucks from the usability perspective?
>>>>      >
>>>>
>>>>      The overlay exists because we can't distribute EAP within community.
>>>>      Keycloak should be run as a separate server, so, IMO, -keycloak.xml
>>>>      files should go away and overwrite standalone.xml,
>>>>      standalone-ha.xml and
>>>>      domain.xml
>>>>
>>>>      > I honestly don't know what's the best way regarding usability. AFAIK
>>>>      > this was decided on mailing lists couple of months ago, but don't
>>>>      > remember the exact threads...:/
>>>>      >
>>>>
>>>>      I'm pretty adamant about this.  There will be a huge amount of
>>>>      confusion
>>>>      if we don't make this separation.  Wildfly/JBoss and Keycloak are hard
>>>>      enough to configure as it is.
>>>>
>>>>
>>>>      --
>>>>      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
>>>>
>>> -- 
>>> 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
> _______________________________________________
> 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  Sun Apr 24 18:05:52 2016
From: bburke at redhat.com (Bill Burke)
Date: Sun, 24 Apr 2016 18:05:52 -0400
Subject: [keycloak-dev] server distro BROKEN
Message-ID: <571D4340.6070008@redhat.com>

Doesn't boot anymore on 1.9.x build (not sure about master).  Built from 
clean clone of keycloak repo.  I'll look at it tomorrow (Monday) unless 
the Europeans can do it.


Caused by: org.jboss.modules.ModuleNotFoundException: 
org.keycloak.keycloak-server-subsystem:main
         at 
org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223) 
[jboss-modules.jar:1.5.1.Final]
         at 
org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178) 
[wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
         ... 8 more

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


From ssilvert at redhat.com  Sun Apr 24 21:32:27 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Sun, 24 Apr 2016 21:32:27 -0400
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571D4340.6070008@redhat.com>
References: <571D4340.6070008@redhat.com>
Message-ID: <571D73AB.3020702@redhat.com>

On 4/24/2016 6:05 PM, Bill Burke wrote:
> Doesn't boot anymore on 1.9.x build (not sure about master).  Built from
> clean clone of keycloak repo.  I'll look at it tomorrow (Monday) unless
> the Europeans can do it.
Are you running from /server-dist/target?  You can't do that any more 
because it doesn't have a /modules/layers.conf file.

I'd be all for having the server-dist include that file.  Not sure why 
it is not in server-dist, but it does get copied over in the final build.
>
>
> Caused by: org.jboss.modules.ModuleNotFoundException:
> org.keycloak.keycloak-server-subsystem:main
>           at
> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> [jboss-modules.jar:1.5.1.Final]
>           at
> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>           ... 8 more
>


From ssilvert at redhat.com  Sun Apr 24 21:41:37 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Sun, 24 Apr 2016 21:41:37 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571D1771.3020405@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com> <571D1771.3020405@redhat.com>
Message-ID: <571D75D1.6020904@redhat.com>


On 4/24/2016 2:58 PM, Bill Burke wrote:
> Completely different.  standalone.sh and domain.sh are completely new
> run.sh variants and run.sh disappeared.
Nope.  If there was no domain.sh we would have kept run.sh. 
standalone.sh does exactly the same thing run.sh used to do. 
Furthermore, run.sh didn't disappear.  It just prints a helpful message.

The situation here is exactly the same.  If there was no "keycloak" 
add-user we would have kept the old one.

Bill, I agree that the current situation is confusing.  Stian, I agree 
that having both "add-user.sh" and "add-user-keycloak.sh" is also confusing.

The WildFly solution isn't pretty, but at least it isn't confusing.

I suppose you could make the whole thing prettier by slapping some extra 
UI into the unified version.  Let it prompt the user for what he really 
wants to do, etc., etc.
>
> add-user.sh is the same script as the old.  and you've already had two
> Red Hat people scratching their heads wondering what happened to
> add-user.sh.
Were you including me?  I complained about this several weeks ago, so 
perhaps you can make that three Red Hat people.  I agree that it's a 
problem.
>
> On 4/23/2016 3:04 PM, Stan Silvert wrote:
>> We had the same kind of problem in WildFly a few years ago.  Everyone
>> was used to starting the server with run.sh.  But we needed to change
>> that to differentiate between standalone.sh and domain.sh.  So we made
>> run.bat just print out a "This is deprecated.  Here is what you need to
>> do...." message.
>>
>> It's not a perfect solution, but we could do the same thing with
>> add-user.sh and tell them to use either add-user-keycloak.sh or
>> add-user-eap.sh.  At least you wouldn't get any support questions.
>>
>> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>>> Hello!
>>>
>>> As a new member of keycloak QA team I recently had to set up some
>>> clustering with domain mode.
>>> I was really confused when add-user.sh did not add user to jboss but
>>> rather created the keycloak-add-user.json.
>>> The worst thing was that I couldn't find any docs on adding user to
>>> underlying eap at all.
>>> Had to read the add-user.sh itself to find out what was happening.
>>> Even if it remains as it is, it really should be at least mentioned in
>>> the docs :)
>>>
>>> Have a nice day!
>>> Ilya Rum.
>>>
>>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>>>> Do you care about usability at all?  Not everything can fit into nice little
>>>> boxes all the time.  This is going to be extremely confusing for users.  I
>>>> ran into it myself as I thought the jboss add-user.sh script was overwritten
>>>> by our distribution script by mistake.  *OF COURSE* we should have a
>>>> separate add-user.sh script. Even when, hopefully, JBoss can delegate to
>>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and
>>>> this means the JBoss documentation too, every management function that
>>>> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*.  If
>>>> we don't change this, we're going to get a ton of support questions that
>>>> say: "Why doesn't add-user.sh work?"
>>>>
>>>>
>>>>
>>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>>>> In the future we need to secure the underlying WildFly with rhsso. In
>>>>> which case our add-user will add users for both Keycloak and WildFly/EAP.
>>>>>
>>>>> IMO there's going to be confusion until the above is solved no matter what
>>>>> we do. We'll need to document this whichever way we do it. Options are
>>>>> stay with what we have or rename our script. My vote goes to keep as is
>>>>> and document it. Then hopefully by 7.1 we can secure the WildFly bits so
>>>>> the problem goes away. With the other option (rename ours) there will be a
>>>>> problem once WildFly bits are secured by Keycloak as now the wf add-user
>>>>> script should no longer be used and completely removed at which point we
>>>>> should then rename it back. So in the long run sticking with how it is
>>>>> today is ideal. It's also way to late making changes now. BTW this has
>>>>> been around for months.
>>>>>
>>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>>>>> <mailto:bburke at redhat.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>       On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>>>>       > That's the question...
>>>>>       >
>>>>>       > For server distribution, we also have our stuff ( keycloak
>>>>>       subsystem,
>>>>>       > datasource, infinispan etc) directly declared in
>>>>>       "standalone.xml". On
>>>>>       > the other hand, for overlay distribution, we don't want to directly
>>>>>       > update default "standalone.xml", so we are adding our own
>>>>>       > "standalone-keycloak.xml". Isn't it quite similar thing?
>>>>>       >
>>>>>
>>>>>       Product will not have the overlay distribution.
>>>>>
>>>>>       > We can do the same for overlay and server distribution, so never
>>>>>       edit
>>>>>       > default wildfly files ( standalone.xml , add-user.sh), but
>>>>>       always use
>>>>>       > our own versions with "-keycloak" suffix. Advantage is more
>>>>>       > consistent. However people will need to always start keycloak server
>>>>>       > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it
>>>>>       > sucks from the usability perspective?
>>>>>       >
>>>>>
>>>>>       The overlay exists because we can't distribute EAP within community.
>>>>>       Keycloak should be run as a separate server, so, IMO, -keycloak.xml
>>>>>       files should go away and overwrite standalone.xml,
>>>>>       standalone-ha.xml and
>>>>>       domain.xml
>>>>>
>>>>>       > I honestly don't know what's the best way regarding usability. AFAIK
>>>>>       > this was decided on mailing lists couple of months ago, but don't
>>>>>       > remember the exact threads...:/
>>>>>       >
>>>>>
>>>>>       I'm pretty adamant about this.  There will be a huge amount of
>>>>>       confusion
>>>>>       if we don't make this separation.  Wildfly/JBoss and Keycloak are hard
>>>>>       enough to configure as it is.
>>>>>
>>>>>
>>>>>       --
>>>>>       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
>>>>>
>>>> -- 
>>>> 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
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Sun Apr 24 21:49:47 2016
From: bburke at redhat.com (Bill Burke)
Date: Sun, 24 Apr 2016 21:49:47 -0400
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571D73AB.3020702@redhat.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
Message-ID: <571D77BB.1030005@redhat.com>

What final build?

On 4/24/2016 9:32 PM, Stan Silvert wrote:
> On 4/24/2016 6:05 PM, Bill Burke wrote:
>> Doesn't boot anymore on 1.9.x build (not sure about master).  Built from
>> clean clone of keycloak repo.  I'll look at it tomorrow (Monday) unless
>> the Europeans can do it.
> Are you running from /server-dist/target?  You can't do that any more
> because it doesn't have a /modules/layers.conf file.
>
> I'd be all for having the server-dist include that file.  Not sure why
> it is not in server-dist, but it does get copied over in the final build.
>>
>> Caused by: org.jboss.modules.ModuleNotFoundException:
>> org.keycloak.keycloak-server-subsystem:main
>>            at
>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>> [jboss-modules.jar:1.5.1.Final]
>>            at
>> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>>            ... 8 more
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From ssilvert at redhat.com  Sun Apr 24 21:50:14 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Sun, 24 Apr 2016 21:50:14 -0400
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571D77BB.1030005@redhat.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com>
Message-ID: <571D77D6.6080203@redhat.com>

On 4/24/2016 9:49 PM, Bill Burke wrote:
> What final build?
The one that actually makes it to the download.  It's been like this for 
a while so it must be working.  I really don't know the details.
>
> On 4/24/2016 9:32 PM, Stan Silvert wrote:
>> On 4/24/2016 6:05 PM, Bill Burke wrote:
>>> Doesn't boot anymore on 1.9.x build (not sure about master).  Built from
>>> clean clone of keycloak repo.  I'll look at it tomorrow (Monday) unless
>>> the Europeans can do it.
>> Are you running from /server-dist/target?  You can't do that any more
>> because it doesn't have a /modules/layers.conf file.
>>
>> I'd be all for having the server-dist include that file.  Not sure why
>> it is not in server-dist, but it does get copied over in the final build.
>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>>> org.keycloak.keycloak-server-subsystem:main
>>>             at
>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>>> [jboss-modules.jar:1.5.1.Final]
>>>             at
>>> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>>>             ... 8 more
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Sun Apr 24 22:14:35 2016
From: bburke at redhat.com (Bill Burke)
Date: Sun, 24 Apr 2016 22:14:35 -0400
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571D77D6.6080203@redhat.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com> <571D77D6.6080203@redhat.com>
Message-ID: <571D7D8B.5000304@redhat.com>

What download are you talking about RH-SSO?

On 4/24/2016 9:50 PM, Stan Silvert wrote:
> On 4/24/2016 9:49 PM, Bill Burke wrote:
>> What final build?
> The one that actually makes it to the download.  It's been like this for
> a while so it must be working.  I really don't know the details.
>> On 4/24/2016 9:32 PM, Stan Silvert wrote:
>>> On 4/24/2016 6:05 PM, Bill Burke wrote:
>>>> Doesn't boot anymore on 1.9.x build (not sure about master).  Built from
>>>> clean clone of keycloak repo.  I'll look at it tomorrow (Monday) unless
>>>> the Europeans can do it.
>>> Are you running from /server-dist/target?  You can't do that any more
>>> because it doesn't have a /modules/layers.conf file.
>>>
>>> I'd be all for having the server-dist include that file.  Not sure why
>>> it is not in server-dist, but it does get copied over in the final build.
>>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>>>> org.keycloak.keycloak-server-subsystem:main
>>>>              at
>>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>>>> [jboss-modules.jar:1.5.1.Final]
>>>>              at
>>>> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>>>>              ... 8 more
>>>>
>>> _______________________________________________
>>> 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  Sun Apr 24 22:17:47 2016
From: bburke at redhat.com (Bill Burke)
Date: Sun, 24 Apr 2016 22:17:47 -0400
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571D7D8B.5000304@redhat.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com> <571D77D6.6080203@redhat.com>
	<571D7D8B.5000304@redhat.com>
Message-ID: <571D7E4B.1000706@redhat.com>

I'm losing my mind... The unzip has it...

On 4/24/2016 10:14 PM, Bill Burke wrote:
> What download are you talking about RH-SSO?
>
> On 4/24/2016 9:50 PM, Stan Silvert wrote:
>> On 4/24/2016 9:49 PM, Bill Burke wrote:
>>> What final build?
>> The one that actually makes it to the download.  It's been like this for
>> a while so it must be working.  I really don't know the details.
>>> On 4/24/2016 9:32 PM, Stan Silvert wrote:
>>>> On 4/24/2016 6:05 PM, Bill Burke wrote:
>>>>> Doesn't boot anymore on 1.9.x build (not sure about master).  Built from
>>>>> clean clone of keycloak repo.  I'll look at it tomorrow (Monday) unless
>>>>> the Europeans can do it.
>>>> Are you running from /server-dist/target?  You can't do that any more
>>>> because it doesn't have a /modules/layers.conf file.
>>>>
>>>> I'd be all for having the server-dist include that file.  Not sure why
>>>> it is not in server-dist, but it does get copied over in the final build.
>>>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>>>>> org.keycloak.keycloak-server-subsystem:main
>>>>>               at
>>>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>>>>> [jboss-modules.jar:1.5.1.Final]
>>>>>               at
>>>>> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>>>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>>>>>               ... 8 more
>>>>>
>>>> _______________________________________________
>>>> 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 wadahiro at gmail.com  Mon Apr 25 00:40:01 2016
From: wadahiro at gmail.com (Hiroyuki Wada)
Date: Mon, 25 Apr 2016 13:40:01 +0900
Subject: [keycloak-dev] MaxBuffer setting in SamlFilter
In-Reply-To: <57177F1E.4040903@redhat.com>
References: <CAPq3NeG0w=OQPHpTBU5er98874yQTMsSWeTHH+qhxBGm27yh-g@mail.gmail.com>
	<57162C89.2010003@redhat.com>
	<CAPq3NeGMmmnTbh4WorYSB0hvAc=x3LcxChv9MzkV32ou0iPfLg@mail.gmail.com>
	<57177F1E.4040903@redhat.com>
Message-ID: <CAPq3NeHV_O-PM2PRNxBDQimiv__arL=b2HQ=pMm9G+XmtajLtg@mail.gmail.com>

OK, I created a ticket.

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

On Wed, Apr 20, 2016 at 10:07 PM, Bill Burke <bburke at redhat.com> wrote:
> log a jira then and we'll get to it sometime when we get back to 2.0
> development.  I can't accept a fix only for one place.
>
> On 4/19/2016 11:02 PM, wadahiro wrote:
>> It looks like hard to set it across all adapters because the
>> bufferSize is set and used by external dependent library of the SAML
>> Adapter except for SamlFilter.
>> For example, the bufferSize is used in the Undertow class
>> 'io.undertow.servlet.util.SavedRequest' when we use Wildfly SAML
>> Adapter as follows.
>>
>> https://github.com/undertow-io/undertow/blob/1.3.21.Final/servlet/src/main/java/io/undertow/servlet/util/SavedRequest.java#L72
>>
>> I think the value is read-only and cannot set it from
>> 'WildflySamlSessionStore.java' in Wildfly SAML Adapter of Keycloak.
>>
>> On Tue, Apr 19, 2016 at 10:03 PM, Bill Burke <bburke at redhat.com> wrote:
>>> Should be a configuration switch in the keycloak-saml.xml file and set
>>> across all adapters.
>>>
>>> On 4/19/2016 5:00 AM, wadahiro wrote:
>>>> Hi,
>>>>
>>>> I had evaluated Keyloak SAML Client Adapter a month ago.
>>>> As a result, I noticed that 'SamlFilter.java' does not support
>>>> maxBuffer setting. It was hard-coded with '100000' currently.
>>>> I want to propose that we can set it in 'WEB-INF/web.xml', how about
>>>> you ? I can send a pull request with the following changes.
>>>>
>>>> https://github.com/wadahiro/keycloak/commit/0d283caccf5369ae6c48c5530e1a23955f29c64d
>>>>
>>>> Regards,
>>>> Hiroyuki Wada
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
> 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 sthorger at redhat.com  Mon Apr 25 03:35:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Apr 2016 09:35:43 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571D75D1.6020904@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com> <571D1771.3020405@redhat.com>
	<571D75D1.6020904@redhat.com>
Message-ID: <CAJgngAfR+XsrCen-xDJe9Ajv0WhYC7RjJuA9zUfLZpukxBcQRQ@mail.gmail.com>

Seems like the majority (that being everyone besides me) would like to have
the script renamed. So let's go for it, but first I have two questions:

a) What should it be called (it can't be add-user-keycloak.sh as then it
wouldn't make sense in product)? add-user-sso.sh is an idea, but is it
clear that's adding "Keycloak admin console" users
b) Will we not get a bunch of people asking "I added a user with add-user,
but still can't login to Keycloak admin console"? Do we have a solution for
that?

On 25 April 2016 at 03:41, Stan Silvert <ssilvert at redhat.com> wrote:

>
> On 4/24/2016 2:58 PM, Bill Burke wrote:
> > Completely different.  standalone.sh and domain.sh are completely new
> > run.sh variants and run.sh disappeared.
> Nope.  If there was no domain.sh we would have kept run.sh.
> standalone.sh does exactly the same thing run.sh used to do.
> Furthermore, run.sh didn't disappear.  It just prints a helpful message.
>
> The situation here is exactly the same.  If there was no "keycloak"
> add-user we would have kept the old one.
>
> Bill, I agree that the current situation is confusing.  Stian, I agree
> that having both "add-user.sh" and "add-user-keycloak.sh" is also
> confusing.
>
> The WildFly solution isn't pretty, but at least it isn't confusing.
>
> I suppose you could make the whole thing prettier by slapping some extra
> UI into the unified version.  Let it prompt the user for what he really
> wants to do, etc., etc.
> >
> > add-user.sh is the same script as the old.  and you've already had two
> > Red Hat people scratching their heads wondering what happened to
> > add-user.sh.
> Were you including me?  I complained about this several weeks ago, so
> perhaps you can make that three Red Hat people.  I agree that it's a
> problem.
> >
> > On 4/23/2016 3:04 PM, Stan Silvert wrote:
> >> We had the same kind of problem in WildFly a few years ago.  Everyone
> >> was used to starting the server with run.sh.  But we needed to change
> >> that to differentiate between standalone.sh and domain.sh.  So we made
> >> run.bat just print out a "This is deprecated.  Here is what you need to
> >> do...." message.
> >>
> >> It's not a perfect solution, but we could do the same thing with
> >> add-user.sh and tell them to use either add-user-keycloak.sh or
> >> add-user-eap.sh.  At least you wouldn't get any support questions.
> >>
> >> On 4/23/2016 9:06 AM, Ilya Rum wrote:
> >>> Hello!
> >>>
> >>> As a new member of keycloak QA team I recently had to set up some
> >>> clustering with domain mode.
> >>> I was really confused when add-user.sh did not add user to jboss but
> >>> rather created the keycloak-add-user.json.
> >>> The worst thing was that I couldn't find any docs on adding user to
> >>> underlying eap at all.
> >>> Had to read the add-user.sh itself to find out what was happening.
> >>> Even if it remains as it is, it really should be at least mentioned in
> >>> the docs :)
> >>>
> >>> Have a nice day!
> >>> Ilya Rum.
> >>>
> >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
> >>>> Do you care about usability at all?  Not everything can fit into nice
> little
> >>>> boxes all the time.  This is going to be extremely confusing for
> users.  I
> >>>> ran into it myself as I thought the jboss add-user.sh script was
> overwritten
> >>>> by our distribution script by mistake.  *OF COURSE* we should have a
> >>>> separate add-user.sh script. Even when, hopefully, JBoss can delegate
> to
> >>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss
> platform, and
> >>>> this means the JBoss documentation too, every management function that
> >>>> exists in JBoss should be available in Keycloak and *WORK THE SAME
> WAY*.  If
> >>>> we don't change this, we're going to get a ton of support questions
> that
> >>>> say: "Why doesn't add-user.sh work?"
> >>>>
> >>>>
> >>>>
> >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
> >>>>> In the future we need to secure the underlying WildFly with rhsso. In
> >>>>> which case our add-user will add users for both Keycloak and
> WildFly/EAP.
> >>>>>
> >>>>> IMO there's going to be confusion until the above is solved no
> matter what
> >>>>> we do. We'll need to document this whichever way we do it. Options
> are
> >>>>> stay with what we have or rename our script. My vote goes to keep as
> is
> >>>>> and document it. Then hopefully by 7.1 we can secure the WildFly
> bits so
> >>>>> the problem goes away. With the other option (rename ours) there
> will be a
> >>>>> problem once WildFly bits are secured by Keycloak as now the wf
> add-user
> >>>>> script should no longer be used and completely removed at which
> point we
> >>>>> should then rename it back. So in the long run sticking with how it
> is
> >>>>> today is ideal. It's also way to late making changes now. BTW this
> has
> >>>>> been around for months.
> >>>>>
> >>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
> >>>>> <mailto:bburke at redhat.com>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>       On 4/22/2016 3:57 PM, Marek Posolda wrote:
> >>>>>       > That's the question...
> >>>>>       >
> >>>>>       > For server distribution, we also have our stuff ( keycloak
> >>>>>       subsystem,
> >>>>>       > datasource, infinispan etc) directly declared in
> >>>>>       "standalone.xml". On
> >>>>>       > the other hand, for overlay distribution, we don't want to
> directly
> >>>>>       > update default "standalone.xml", so we are adding our own
> >>>>>       > "standalone-keycloak.xml". Isn't it quite similar thing?
> >>>>>       >
> >>>>>
> >>>>>       Product will not have the overlay distribution.
> >>>>>
> >>>>>       > We can do the same for overlay and server distribution, so
> never
> >>>>>       edit
> >>>>>       > default wildfly files ( standalone.xml , add-user.sh), but
> >>>>>       always use
> >>>>>       > our own versions with "-keycloak" suffix. Advantage is more
> >>>>>       > consistent. However people will need to always start
> keycloak server
> >>>>>       > with "./standalone.sh -c standalone-keycloak.xml" then.
> Doesn't it
> >>>>>       > sucks from the usability perspective?
> >>>>>       >
> >>>>>
> >>>>>       The overlay exists because we can't distribute EAP within
> community.
> >>>>>       Keycloak should be run as a separate server, so, IMO,
> -keycloak.xml
> >>>>>       files should go away and overwrite standalone.xml,
> >>>>>       standalone-ha.xml and
> >>>>>       domain.xml
> >>>>>
> >>>>>       > I honestly don't know what's the best way regarding
> usability. AFAIK
> >>>>>       > this was decided on mailing lists couple of months ago, but
> don't
> >>>>>       > remember the exact threads...:/
> >>>>>       >
> >>>>>
> >>>>>       I'm pretty adamant about this.  There will be a huge amount of
> >>>>>       confusion
> >>>>>       if we don't make this separation.  Wildfly/JBoss and Keycloak
> are hard
> >>>>>       enough to configure as it is.
> >>>>>
> >>>>>
> >>>>>       --
> >>>>>       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
> >>>>>
> >>>> --
> >>>> 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
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/6a142ac1/attachment-0001.html 

From sthorger at redhat.com  Mon Apr 25 03:55:33 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Apr 2016 09:55:33 +0200
Subject: [keycloak-dev] domain mode changes
In-Reply-To: <571D14BE.9040701@redhat.com>
References: <571A70BD.50300@redhat.com>
	<CAJgngAc9d6vs3kipgODmrBrP_iZZvVadn4wsvXW0nbuM=j9frQ@mail.gmail.com>
	<571B701C.5030202@redhat.com> <571D08C0.2040508@redhat.com>
	<571D14BE.9040701@redhat.com>
Message-ID: <CAJgngAf+ZgpOUFF4H3EzDq6B4JqZ7izbgK20kFfrE_=gPjGYOA@mail.gmail.com>

You're not just going ahead and changing this! That's not the way we do
things. If you do we will have a problem.

However, we can discuss it rationally if you want. My issues with this are:

a) Late changes. Introducing what is essentially a new feature, which would
need to be tested and confirmed by QA. You will never get QA guys to do
this, they are swamped. You'd have to write an automated test for this
setup at the very least, but QA would still need to have time to verify.
This would have to be accepted by QA first or it would be marked as tech
preview.

b) The setup doesn't make sense. Most people use NGINX or Apache for
loadbalancer, not Undertow.

c) The setup won't actually work. H2 kinda works if you point to a shared
database, but not properly. H2 lazy writes changes to file, so it wouldn't
work for concurrent requests. You'd have to setup an embedded H2 server
with the TCP connection.

d) Domain mode is not just for clustering. It's to manage groups of
servers. A perfectly valid domain mode setup could be one domain
controller, one group with one EAP instance, one group with a RH SSO
instance and another group with two RH SSO instances in a cluster.



On 24 April 2016 at 20:47, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 4/24/2016 1:56 PM, Marek Posolda wrote:
>
> Do you think that people will use cluster with 2 nodes on localhost +
> embedded H2 + static loadbalancer in production? I guess not. So having our
> domain.xml "pre-set" to have easy example cluster setup won't help much
> IMO. Customers will be able to setup "easy" cluster in 5 minutes, but they
> will be unaware of all the steps they need to set the real "production"
> cluster.
>
>
> I honestly don't see what the big deal is.  The current default domain
> setup won't work in a cluster either.
>
> I'm changing it... and that's that....It allows me to walk through an
> out-of-the-box example that can run on somebody's laptop.  If either you
> are Stian want to change it back, then you can rewrite the domain section
> of the install guide.
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/45851d55/attachment.html 

From mposolda at redhat.com  Mon Apr 25 04:45:58 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Apr 2016 10:45:58 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <CAJgngAfR+XsrCen-xDJe9Ajv0WhYC7RjJuA9zUfLZpukxBcQRQ@mail.gmail.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com> <571D1771.3020405@redhat.com>
	<571D75D1.6020904@redhat.com>
	<CAJgngAfR+XsrCen-xDJe9Ajv0WhYC7RjJuA9zUfLZpukxBcQRQ@mail.gmail.com>
Message-ID: <571DD946.5010101@redhat.com>

On 25/04/16 09:35, Stian Thorgersen wrote:
> Seems like the majority (that being everyone besides me) would like to 
> have the script renamed. So let's go for it, but first I have two 
> questions:
Btv. I didn't suggest to rename, but keep as is. But always when people 
run "add-user.sh" without "--container", there will be be a big warning 
similar to:

"You are adding Keycloak admin, but not Wildfly admin!!! If you want to 
add Wildfly admin use the option --container"

This should solve both your (a) and (b) and remove most of confusions 
IMO. And in the future version, when keycloak and wildfly admin will be 
same thing, we can still use same "add-user.sh" script without need to 
rename, remove or add any new script. We will just remove the warning 
and possibly support for "--container" option.


Marek

>
> a) What should it be called (it can't be add-user-keycloak.sh as then 
> it wouldn't make sense in product)? add-user-sso.sh is an idea, but is 
> it clear that's adding "Keycloak admin console" users
> b) Will we not get a bunch of people asking "I added a user with 
> add-user, but still can't login to Keycloak admin console"? Do we have 
> a solution for that?
>
> On 25 April 2016 at 03:41, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>
>     On 4/24/2016 2:58 PM, Bill Burke wrote:
>     > Completely different.  standalone.sh and domain.sh are
>     completely new
>     > run.sh variants and run.sh disappeared.
>     Nope.  If there was no domain.sh we would have kept run.sh.
>     standalone.sh does exactly the same thing run.sh used to do.
>     Furthermore, run.sh didn't disappear.  It just prints a helpful
>     message.
>
>     The situation here is exactly the same.  If there was no "keycloak"
>     add-user we would have kept the old one.
>
>     Bill, I agree that the current situation is confusing. Stian, I agree
>     that having both "add-user.sh" and "add-user-keycloak.sh" is also
>     confusing.
>
>     The WildFly solution isn't pretty, but at least it isn't confusing.
>
>     I suppose you could make the whole thing prettier by slapping some
>     extra
>     UI into the unified version.  Let it prompt the user for what he
>     really
>     wants to do, etc., etc.
>     >
>     > add-user.sh is the same script as the old.  and you've already
>     had two
>     > Red Hat people scratching their heads wondering what happened to
>     > add-user.sh.
>     Were you including me?  I complained about this several weeks ago, so
>     perhaps you can make that three Red Hat people.  I agree that it's a
>     problem.
>     >
>     > On 4/23/2016 3:04 PM, Stan Silvert wrote:
>     >> We had the same kind of problem in WildFly a few years ago. 
>     Everyone
>     >> was used to starting the server with run.sh. But we needed to
>     change
>     >> that to differentiate between standalone.sh and domain.sh.  So
>     we made
>     >> run.bat just print out a "This is deprecated. Here is what you
>     need to
>     >> do...." message.
>     >>
>     >> It's not a perfect solution, but we could do the same thing with
>     >> add-user.sh and tell them to use either add-user-keycloak.sh or
>     >> add-user-eap.sh.  At least you wouldn't get any support questions.
>     >>
>     >> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>     >>> Hello!
>     >>>
>     >>> As a new member of keycloak QA team I recently had to set up some
>     >>> clustering with domain mode.
>     >>> I was really confused when add-user.sh did not add user to
>     jboss but
>     >>> rather created the keycloak-add-user.json.
>     >>> The worst thing was that I couldn't find any docs on adding
>     user to
>     >>> underlying eap at all.
>     >>> Had to read the add-user.sh itself to find out what was happening.
>     >>> Even if it remains as it is, it really should be at least
>     mentioned in
>     >>> the docs :)
>     >>>
>     >>> Have a nice day!
>     >>> Ilya Rum.
>     >>>
>     >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>     >>>> Do you care about usability at all? Not everything can fit
>     into nice little
>     >>>> boxes all the time.  This is going to be extremely confusing
>     for users.  I
>     >>>> ran into it myself as I thought the jboss add-user.sh script
>     was overwritten
>     >>>> by our distribution script by mistake. *OF COURSE* we should
>     have a
>     >>>> separate add-user.sh script. Even when, hopefully, JBoss can
>     delegate to
>     >>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss
>     platform, and
>     >>>> this means the JBoss documentation too, every management
>     function that
>     >>>> exists in JBoss should be available in Keycloak and *WORK THE
>     SAME WAY*.  If
>     >>>> we don't change this, we're going to get a ton of support
>     questions that
>     >>>> say: "Why doesn't add-user.sh work?"
>     >>>>
>     >>>>
>     >>>>
>     >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>     >>>>> In the future we need to secure the underlying WildFly with
>     rhsso. In
>     >>>>> which case our add-user will add users for both Keycloak and
>     WildFly/EAP.
>     >>>>>
>     >>>>> IMO there's going to be confusion until the above is solved
>     no matter what
>     >>>>> we do. We'll need to document this whichever way we do it.
>     Options are
>     >>>>> stay with what we have or rename our script. My vote goes to
>     keep as is
>     >>>>> and document it. Then hopefully by 7.1 we can secure the
>     WildFly bits so
>     >>>>> the problem goes away. With the other option (rename ours)
>     there will be a
>     >>>>> problem once WildFly bits are secured by Keycloak as now the
>     wf add-user
>     >>>>> script should no longer be used and completely removed at
>     which point we
>     >>>>> should then rename it back. So in the long run sticking with
>     how it is
>     >>>>> today is ideal. It's also way to late making changes now.
>     BTW this has
>     >>>>> been around for months.
>     >>>>>
>     >>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>     <mailto:bburke at redhat.com>
>     >>>>> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> wrote:
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>       On 4/22/2016 3:57 PM, Marek Posolda wrote:
>     >>>>>       > That's the question...
>     >>>>>       >
>     >>>>>       > For server distribution, we also have our stuff (
>     keycloak
>     >>>>>       subsystem,
>     >>>>>       > datasource, infinispan etc) directly declared in
>     >>>>>       "standalone.xml". On
>     >>>>>       > the other hand, for overlay distribution, we don't
>     want to directly
>     >>>>>       > update default "standalone.xml", so we are adding
>     our own
>     >>>>>       > "standalone-keycloak.xml". Isn't it quite similar thing?
>     >>>>>       >
>     >>>>>
>     >>>>>       Product will not have the overlay distribution.
>     >>>>>
>     >>>>>       > We can do the same for overlay and server
>     distribution, so never
>     >>>>>       edit
>     >>>>>       > default wildfly files ( standalone.xml ,
>     add-user.sh), but
>     >>>>>       always use
>     >>>>>       > our own versions with "-keycloak" suffix. Advantage
>     is more
>     >>>>>       > consistent. However people will need to always start
>     keycloak server
>     >>>>>       > with "./standalone.sh -c standalone-keycloak.xml"
>     then. Doesn't it
>     >>>>>       > sucks from the usability perspective?
>     >>>>>       >
>     >>>>>
>     >>>>>       The overlay exists because we can't distribute EAP
>     within community.
>     >>>>>       Keycloak should be run as a separate server, so, IMO,
>     -keycloak.xml
>     >>>>>       files should go away and overwrite standalone.xml,
>     >>>>>       standalone-ha.xml and
>     >>>>>       domain.xml
>     >>>>>
>     >>>>>       > I honestly don't know what's the best way regarding
>     usability. AFAIK
>     >>>>>       > this was decided on mailing lists couple of months
>     ago, but don't
>     >>>>>       > remember the exact threads...:/
>     >>>>>       >
>     >>>>>
>     >>>>>       I'm pretty adamant about this.  There will be a huge
>     amount of
>     >>>>>       confusion
>     >>>>>       if we don't make this separation.  Wildfly/JBoss and
>     Keycloak are hard
>     >>>>>       enough to configure as it is.
>     >>>>>
>     >>>>>
>     >>>>>       --
>     >>>>>       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>
>     <mailto:keycloak-dev at lists.jboss.org
>     <mailto: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
>     <mailto:keycloak-dev at lists.jboss.org>
>     >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >>> _______________________________________________
>     >>> keycloak-dev mailing list
>     >>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >> _______________________________________________
>     >> keycloak-dev mailing list
>     >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> 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/20160425/3c849092/attachment-0001.html 

From sthorger at redhat.com  Mon Apr 25 04:56:15 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Apr 2016 10:56:15 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571DD946.5010101@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com> <571D1771.3020405@redhat.com>
	<571D75D1.6020904@redhat.com>
	<CAJgngAfR+XsrCen-xDJe9Ajv0WhYC7RjJuA9zUfLZpukxBcQRQ@mail.gmail.com>
	<571DD946.5010101@redhat.com>
Message-ID: <CAJgngAezaW7pqAZ=70vdSi_-C4g6FVJxUfzL3mmGyQj9Uy4hbQ@mail.gmail.com>

+1 To what Marek is proposing

I'd suggest a slightly more mellow tone though. Rather than the current
message (which is a bit rubbish):

   Added 'k' to
'/home/st/tmp/keycloak-1.9.2.Final/standalone/configuration/keycloak-add-user.json',
restart server to load user

We could do:

  Keycloak admin user added, please restart server to make the user
available. To add user for jboss-cli please run "add-user" with
"--container" option.

Other improvements we could do are:

* "--container" description should be "Add user to jboss-cli. For usage use
'--container --help'"
* When add-user is run without options it currently says 'Option: -u.. is
required' it should instead display help text (--help) and the help text
should have a paragraph on the bottom stating how the user is added, that
the server needs to be reloaded and also how to add a user to jboss-cli.

I'm happy to incorporate the above changes if that's what we agree on.

On 25 April 2016 at 10:45, Marek Posolda <mposolda at redhat.com> wrote:

> On 25/04/16 09:35, Stian Thorgersen wrote:
>
> Seems like the majority (that being everyone besides me) would like to
> have the script renamed. So let's go for it, but first I have two questions:
>
> Btv. I didn't suggest to rename, but keep as is. But always when people
> run "add-user.sh" without "--container", there will be be a big warning
> similar to:
>
> "You are adding Keycloak admin, but not Wildfly admin!!! If you want to
> add Wildfly admin use the option --container"
>
> This should solve both your (a) and (b) and remove most of confusions IMO.
> And in the future version, when keycloak and wildfly admin will be same
> thing, we can still use same "add-user.sh" script without need to rename,
> remove or add any new script. We will just remove the warning and possibly
> support for "--container" option.
>
>
> Marek
>
>
>
> a) What should it be called (it can't be add-user-keycloak.sh as then it
> wouldn't make sense in product)? add-user-sso.sh is an idea, but is it
> clear that's adding "Keycloak admin console" users
> b) Will we not get a bunch of people asking "I added a user with add-user,
> but still can't login to Keycloak admin console"? Do we have a solution for
> that?
>
> On 25 April 2016 at 03:41, Stan Silvert <ssilvert at redhat.com> wrote:
>
>>
>> On 4/24/2016 2:58 PM, Bill Burke wrote:
>> > Completely different.  standalone.sh and domain.sh are completely new
>> > run.sh variants and run.sh disappeared.
>> Nope.  If there was no domain.sh we would have kept run.sh.
>> standalone.sh does exactly the same thing run.sh used to do.
>> Furthermore, run.sh didn't disappear.  It just prints a helpful message.
>>
>> The situation here is exactly the same.  If there was no "keycloak"
>> add-user we would have kept the old one.
>>
>> Bill, I agree that the current situation is confusing.  Stian, I agree
>> that having both "add-user.sh" and "add-user-keycloak.sh" is also
>> confusing.
>>
>> The WildFly solution isn't pretty, but at least it isn't confusing.
>>
>> I suppose you could make the whole thing prettier by slapping some extra
>> UI into the unified version.  Let it prompt the user for what he really
>> wants to do, etc., etc.
>> >
>> > add-user.sh is the same script as the old.  and you've already had two
>> > Red Hat people scratching their heads wondering what happened to
>> > add-user.sh.
>> Were you including me?  I complained about this several weeks ago, so
>> perhaps you can make that three Red Hat people.  I agree that it's a
>> problem.
>> >
>> > On 4/23/2016 3:04 PM, Stan Silvert wrote:
>> >> We had the same kind of problem in WildFly a few years ago.  Everyone
>> >> was used to starting the server with run.sh.  But we needed to change
>> >> that to differentiate between standalone.sh and domain.sh.  So we made
>> >> run.bat just print out a "This is deprecated.  Here is what you need to
>> >> do...." message.
>> >>
>> >> It's not a perfect solution, but we could do the same thing with
>> >> add-user.sh and tell them to use either add-user-keycloak.sh or
>> >> add-user-eap.sh.  At least you wouldn't get any support questions.
>> >>
>> >> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>> >>> Hello!
>> >>>
>> >>> As a new member of keycloak QA team I recently had to set up some
>> >>> clustering with domain mode.
>> >>> I was really confused when add-user.sh did not add user to jboss but
>> >>> rather created the keycloak-add-user.json.
>> >>> The worst thing was that I couldn't find any docs on adding user to
>> >>> underlying eap at all.
>> >>> Had to read the add-user.sh itself to find out what was happening.
>> >>> Even if it remains as it is, it really should be at least mentioned in
>> >>> the docs :)
>> >>>
>> >>> Have a nice day!
>> >>> Ilya Rum.
>> >>>
>> >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>> >>>> Do you care about usability at all?  Not everything can fit into
>> nice little
>> >>>> boxes all the time.  This is going to be extremely confusing for
>> users.  I
>> >>>> ran into it myself as I thought the jboss add-user.sh script was
>> overwritten
>> >>>> by our distribution script by mistake.  *OF COURSE* we should have a
>> >>>> separate add-user.sh script. Even when, hopefully, JBoss can
>> delegate to
>> >>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss
>> platform, and
>> >>>> this means the JBoss documentation too, every management function
>> that
>> >>>> exists in JBoss should be available in Keycloak and *WORK THE SAME
>> WAY*.  If
>> >>>> we don't change this, we're going to get a ton of support questions
>> that
>> >>>> say: "Why doesn't add-user.sh work?"
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>> >>>>> In the future we need to secure the underlying WildFly with rhsso.
>> In
>> >>>>> which case our add-user will add users for both Keycloak and
>> WildFly/EAP.
>> >>>>>
>> >>>>> IMO there's going to be confusion until the above is solved no
>> matter what
>> >>>>> we do. We'll need to document this whichever way we do it. Options
>> are
>> >>>>> stay with what we have or rename our script. My vote goes to keep
>> as is
>> >>>>> and document it. Then hopefully by 7.1 we can secure the WildFly
>> bits so
>> >>>>> the problem goes away. With the other option (rename ours) there
>> will be a
>> >>>>> problem once WildFly bits are secured by Keycloak as now the wf
>> add-user
>> >>>>> script should no longer be used and completely removed at which
>> point we
>> >>>>> should then rename it back. So in the long run sticking with how it
>> is
>> >>>>> today is ideal. It's also way to late making changes now. BTW this
>> has
>> >>>>> been around for months.
>> >>>>>
>> >>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>> >>>>> <mailto: <bburke at redhat.com>bburke at redhat.com>> wrote:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>       On 4/22/2016 3:57 PM, Marek Posolda wrote:
>> >>>>>       > That's the question...
>> >>>>>       >
>> >>>>>       > For server distribution, we also have our stuff ( keycloak
>> >>>>>       subsystem,
>> >>>>>       > datasource, infinispan etc) directly declared in
>> >>>>>       "standalone.xml". On
>> >>>>>       > the other hand, for overlay distribution, we don't want to
>> directly
>> >>>>>       > update default "standalone.xml", so we are adding our own
>> >>>>>       > "standalone-keycloak.xml". Isn't it quite similar thing?
>> >>>>>       >
>> >>>>>
>> >>>>>       Product will not have the overlay distribution.
>> >>>>>
>> >>>>>       > We can do the same for overlay and server distribution, so
>> never
>> >>>>>       edit
>> >>>>>       > default wildfly files ( standalone.xml , add-user.sh), but
>> >>>>>       always use
>> >>>>>       > our own versions with "-keycloak" suffix. Advantage is more
>> >>>>>       > consistent. However people will need to always start
>> keycloak server
>> >>>>>       > with "./standalone.sh -c standalone-keycloak.xml" then.
>> Doesn't it
>> >>>>>       > sucks from the usability perspective?
>> >>>>>       >
>> >>>>>
>> >>>>>       The overlay exists because we can't distribute EAP within
>> community.
>> >>>>>       Keycloak should be run as a separate server, so, IMO,
>> -keycloak.xml
>> >>>>>       files should go away and overwrite standalone.xml,
>> >>>>>       standalone-ha.xml and
>> >>>>>       domain.xml
>> >>>>>
>> >>>>>       > I honestly don't know what's the best way regarding
>> usability. AFAIK
>> >>>>>       > this was decided on mailing lists couple of months ago, but
>> don't
>> >>>>>       > remember the exact threads...:/
>> >>>>>       >
>> >>>>>
>> >>>>>       I'm pretty adamant about this.  There will be a huge amount of
>> >>>>>       confusion
>> >>>>>       if we don't make this separation.  Wildfly/JBoss and Keycloak
>> are hard
>> >>>>>       enough to configure as it is.
>> >>>>>
>> >>>>>
>> >>>>>       --
>> >>>>>       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
>> >>>>>
>> >>>> --
>> >>>> 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
>> >> _______________________________________________
>> >> 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 listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/c0669dd1/attachment-0001.html 

From ssilvert at redhat.com  Mon Apr 25 07:47:13 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 25 Apr 2016 07:47:13 -0400
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571D7E4B.1000706@redhat.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com> <571D77D6.6080203@redhat.com>
	<571D7D8B.5000304@redhat.com> <571D7E4B.1000706@redhat.com>
Message-ID: <571E03C1.4050805@redhat.com>

On 4/24/2016 10:17 PM, Bill Burke wrote:
> I'm losing my mind... The unzip has it...
I felt the same way when I came across that issue.  My personal build 
script copies it over so that I can still run from server-dist/target.
>
> On 4/24/2016 10:14 PM, Bill Burke wrote:
>> What download are you talking about RH-SSO?
>>
>> On 4/24/2016 9:50 PM, Stan Silvert wrote:
>>> On 4/24/2016 9:49 PM, Bill Burke wrote:
>>>> What final build?
>>> The one that actually makes it to the download.  It's been like this for
>>> a while so it must be working.  I really don't know the details.
>>>> On 4/24/2016 9:32 PM, Stan Silvert wrote:
>>>>> On 4/24/2016 6:05 PM, Bill Burke wrote:
>>>>>> Doesn't boot anymore on 1.9.x build (not sure about master).  Built from
>>>>>> clean clone of keycloak repo.  I'll look at it tomorrow (Monday) unless
>>>>>> the Europeans can do it.
>>>>> Are you running from /server-dist/target?  You can't do that any more
>>>>> because it doesn't have a /modules/layers.conf file.
>>>>>
>>>>> I'd be all for having the server-dist include that file.  Not sure why
>>>>> it is not in server-dist, but it does get copied over in the final build.
>>>>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>>>>>> org.keycloak.keycloak-server-subsystem:main
>>>>>>                at
>>>>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>>>>>> [jboss-modules.jar:1.5.1.Final]
>>>>>>                at
>>>>>> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>>>>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>>>>>>                ... 8 more
>>>>>>
>>>>> _______________________________________________
>>>>> 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 ssilvert at redhat.com  Mon Apr 25 07:59:32 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 25 Apr 2016 07:59:32 -0400
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <CAJgngAezaW7pqAZ=70vdSi_-C4g6FVJxUfzL3mmGyQj9Uy4hbQ@mail.gmail.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com> <571D1771.3020405@redhat.com>
	<571D75D1.6020904@redhat.com>
	<CAJgngAfR+XsrCen-xDJe9Ajv0WhYC7RjJuA9zUfLZpukxBcQRQ@mail.gmail.com>
	<571DD946.5010101@redhat.com>
	<CAJgngAezaW7pqAZ=70vdSi_-C4g6FVJxUfzL3mmGyQj9Uy4hbQ@mail.gmail.com>
Message-ID: <571E06A4.60505@redhat.com>

+1.  That's the "prettier" UI option I was talking about.

On 4/25/2016 4:56 AM, Stian Thorgersen wrote:
> +1 To what Marek is proposing
>
> I'd suggest a slightly more mellow tone though. Rather than the 
> current message (which is a bit rubbish):
>
>    Added 'k' to 
> '/home/st/tmp/keycloak-1.9.2.Final/standalone/configuration/keycloak-add-user.json', 
> restart server to load user
>
> We could do:
>
>   Keycloak admin user added, please restart server to make the user 
> available. To add user for jboss-cli please run "add-user" with 
> "--container" option.
>
> Other improvements we could do are:
>
> * "--container" description should be "Add user to jboss-cli. For 
> usage use '--container --help'"
> * When add-user is run without options it currently says 'Option: -u.. 
> is required' it should instead display help text (--help) and the help 
> text should have a paragraph on the bottom stating how the user is 
> added, that the server needs to be reloaded and also how to add a user 
> to jboss-cli.
>
> I'm happy to incorporate the above changes if that's what we agree on.
>
> On 25 April 2016 at 10:45, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 25/04/16 09:35, Stian Thorgersen wrote:
>>     Seems like the majority (that being everyone besides me) would
>>     like to have the script renamed. So let's go for it, but first I
>>     have two questions:
>     Btv. I didn't suggest to rename, but keep as is. But always when
>     people run "add-user.sh" without "--container", there will be be a
>     big warning similar to:
>
>     "You are adding Keycloak admin, but not Wildfly admin!!! If you
>     want to add Wildfly admin use the option --container"
>
>     This should solve both your (a) and (b) and remove most of
>     confusions IMO. And in the future version, when keycloak and
>     wildfly admin will be same thing, we can still use same
>     "add-user.sh" script without need to rename, remove or add any new
>     script. We will just remove the warning and possibly support for
>     "--container" option.
>
>
>     Marek
>
>
>>
>>     a) What should it be called (it can't be add-user-keycloak.sh as
>>     then it wouldn't make sense in product)? add-user-sso.sh is an
>>     idea, but is it clear that's adding "Keycloak admin console" users
>>     b) Will we not get a bunch of people asking "I added a user with
>>     add-user, but still can't login to Keycloak admin console"? Do we
>>     have a solution for that?
>>
>>     On 25 April 2016 at 03:41, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>
>>         On 4/24/2016 2:58 PM, Bill Burke wrote:
>>         > Completely different.  standalone.sh and domain.sh are
>>         completely new
>>         > run.sh variants and run.sh disappeared.
>>         Nope.  If there was no domain.sh we would have kept run.sh.
>>         standalone.sh does exactly the same thing run.sh used to do.
>>         Furthermore, run.sh didn't disappear.  It just prints a
>>         helpful message.
>>
>>         The situation here is exactly the same.  If there was no
>>         "keycloak"
>>         add-user we would have kept the old one.
>>
>>         Bill, I agree that the current situation is confusing. 
>>         Stian, I agree
>>         that having both "add-user.sh" and "add-user-keycloak.sh" is
>>         also confusing.
>>
>>         The WildFly solution isn't pretty, but at least it isn't
>>         confusing.
>>
>>         I suppose you could make the whole thing prettier by slapping
>>         some extra
>>         UI into the unified version.  Let it prompt the user for what
>>         he really
>>         wants to do, etc., etc.
>>         >
>>         > add-user.sh is the same script as the old.  and you've
>>         already had two
>>         > Red Hat people scratching their heads wondering what
>>         happened to
>>         > add-user.sh.
>>         Were you including me?  I complained about this several weeks
>>         ago, so
>>         perhaps you can make that three Red Hat people.  I agree that
>>         it's a
>>         problem.
>>         >
>>         > On 4/23/2016 3:04 PM, Stan Silvert wrote:
>>         >> We had the same kind of problem in WildFly a few years
>>         ago.  Everyone
>>         >> was used to starting the server with run.sh.  But we
>>         needed to change
>>         >> that to differentiate between standalone.sh and
>>         domain.sh.  So we made
>>         >> run.bat just print out a "This is deprecated.  Here is
>>         what you need to
>>         >> do...." message.
>>         >>
>>         >> It's not a perfect solution, but we could do the same
>>         thing with
>>         >> add-user.sh and tell them to use either
>>         add-user-keycloak.sh or
>>         >> add-user-eap.sh.  At least you wouldn't get any support
>>         questions.
>>         >>
>>         >> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>>         >>> Hello!
>>         >>>
>>         >>> As a new member of keycloak QA team I recently had to set
>>         up some
>>         >>> clustering with domain mode.
>>         >>> I was really confused when add-user.sh did not add user
>>         to jboss but
>>         >>> rather created the keycloak-add-user.json.
>>         >>> The worst thing was that I couldn't find any docs on
>>         adding user to
>>         >>> underlying eap at all.
>>         >>> Had to read the add-user.sh itself to find out what was
>>         happening.
>>         >>> Even if it remains as it is, it really should be at least
>>         mentioned in
>>         >>> the docs :)
>>         >>>
>>         >>> Have a nice day!
>>         >>> Ilya Rum.
>>         >>>
>>         >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>>         >>>> Do you care about usability at all?  Not everything can
>>         fit into nice little
>>         >>>> boxes all the time.  This is going to be extremely
>>         confusing for users.  I
>>         >>>> ran into it myself as I thought the jboss add-user.sh
>>         script was overwritten
>>         >>>> by our distribution script by mistake.  *OF COURSE* we
>>         should have a
>>         >>>> separate add-user.sh script. Even when, hopefully, JBoss
>>         can delegate to
>>         >>>> Keycloak in maybe 7.1. If we are going to leverage the
>>         JBoss platform, and
>>         >>>> this means the JBoss documentation too, every management
>>         function that
>>         >>>> exists in JBoss should be available in Keycloak and
>>         *WORK THE SAME WAY*.  If
>>         >>>> we don't change this, we're going to get a ton of
>>         support questions that
>>         >>>> say: "Why doesn't add-user.sh work?"
>>         >>>>
>>         >>>>
>>         >>>>
>>         >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>         >>>>> In the future we need to secure the underlying WildFly
>>         with rhsso. In
>>         >>>>> which case our add-user will add users for both
>>         Keycloak and WildFly/EAP.
>>         >>>>>
>>         >>>>> IMO there's going to be confusion until the above is
>>         solved no matter what
>>         >>>>> we do. We'll need to document this whichever way we do
>>         it. Options are
>>         >>>>> stay with what we have or rename our script. My vote
>>         goes to keep as is
>>         >>>>> and document it. Then hopefully by 7.1 we can secure
>>         the WildFly bits so
>>         >>>>> the problem goes away. With the other option (rename
>>         ours) there will be a
>>         >>>>> problem once WildFly bits are secured by Keycloak as
>>         now the wf add-user
>>         >>>>> script should no longer be used and completely removed
>>         at which point we
>>         >>>>> should then rename it back. So in the long run sticking
>>         with how it is
>>         >>>>> today is ideal. It's also way to late making changes
>>         now. BTW this has
>>         >>>>> been around for months.
>>         >>>>>
>>         >>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>>         <mailto:bburke at redhat.com>
>>         >>>>> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>>
>>         wrote:
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>       On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>         >>>>>       > That's the question...
>>         >>>>>       >
>>         >>>>>       > For server distribution, we also have our stuff
>>         ( keycloak
>>         >>>>>       subsystem,
>>         >>>>>       > datasource, infinispan etc) directly declared in
>>         >>>>>  "standalone.xml". On
>>         >>>>>       > the other hand, for overlay distribution, we
>>         don't want to directly
>>         >>>>>       > update default "standalone.xml", so we are
>>         adding our own
>>         >>>>>       > "standalone-keycloak.xml". Isn't it quite
>>         similar thing?
>>         >>>>>       >
>>         >>>>>
>>         >>>>>       Product will not have the overlay distribution.
>>         >>>>>
>>         >>>>>       > We can do the same for overlay and server
>>         distribution, so never
>>         >>>>>       edit
>>         >>>>>       > default wildfly files ( standalone.xml ,
>>         add-user.sh), but
>>         >>>>>       always use
>>         >>>>>       > our own versions with "-keycloak" suffix.
>>         Advantage is more
>>         >>>>>       > consistent. However people will need to always
>>         start keycloak server
>>         >>>>>       > with "./standalone.sh -c
>>         standalone-keycloak.xml" then. Doesn't it
>>         >>>>>       > sucks from the usability perspective?
>>         >>>>>       >
>>         >>>>>
>>         >>>>>       The overlay exists because we can't distribute
>>         EAP within community.
>>         >>>>>       Keycloak should be run as a separate server, so,
>>         IMO, -keycloak.xml
>>         >>>>>       files should go away and overwrite standalone.xml,
>>         >>>>>  standalone-ha.xml and
>>         >>>>>       domain.xml
>>         >>>>>
>>         >>>>>       > I honestly don't know what's the best way
>>         regarding usability. AFAIK
>>         >>>>>       > this was decided on mailing lists couple of
>>         months ago, but don't
>>         >>>>>       > remember the exact threads...:/
>>         >>>>>       >
>>         >>>>>
>>         >>>>>       I'm pretty adamant about this.  There will be a
>>         huge amount of
>>         >>>>>       confusion
>>         >>>>>       if we don't make this separation.  Wildfly/JBoss
>>         and Keycloak are hard
>>         >>>>>       enough to configure as it is.
>>         >>>>>
>>         >>>>>
>>         >>>>>       --
>>         >>>>>       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>
>>         <mailto:keycloak-dev at lists.jboss.org
>>         <mailto: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
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >>> _______________________________________________
>>         >>> keycloak-dev mailing list
>>         >>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >> _______________________________________________
>>         >> keycloak-dev mailing list
>>         >> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Mon Apr 25 08:03:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Apr 2016 14:03:04 +0200
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571E03C1.4050805@redhat.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com> <571D77D6.6080203@redhat.com>
	<571D7D8B.5000304@redhat.com> <571D7E4B.1000706@redhat.com>
	<571E03C1.4050805@redhat.com>
Message-ID: <CAJgngAfJwfnNmwAO+PW_N=49+FyAU0iYCDAXsaUZh2vTKY4DyQ@mail.gmail.com>

I've just tried a clean build from 1.9.x sources here and it works fine.
What steps do you use to build and run it?

On 25 April 2016 at 13:47, Stan Silvert <ssilvert at redhat.com> wrote:

> On 4/24/2016 10:17 PM, Bill Burke wrote:
> > I'm losing my mind... The unzip has it...
> I felt the same way when I came across that issue.  My personal build
> script copies it over so that I can still run from server-dist/target.
> >
> > On 4/24/2016 10:14 PM, Bill Burke wrote:
> >> What download are you talking about RH-SSO?
> >>
> >> On 4/24/2016 9:50 PM, Stan Silvert wrote:
> >>> On 4/24/2016 9:49 PM, Bill Burke wrote:
> >>>> What final build?
> >>> The one that actually makes it to the download.  It's been like this
> for
> >>> a while so it must be working.  I really don't know the details.
> >>>> On 4/24/2016 9:32 PM, Stan Silvert wrote:
> >>>>> On 4/24/2016 6:05 PM, Bill Burke wrote:
> >>>>>> Doesn't boot anymore on 1.9.x build (not sure about master).  Built
> from
> >>>>>> clean clone of keycloak repo.  I'll look at it tomorrow (Monday)
> unless
> >>>>>> the Europeans can do it.
> >>>>> Are you running from /server-dist/target?  You can't do that any more
> >>>>> because it doesn't have a /modules/layers.conf file.
> >>>>>
> >>>>> I'd be all for having the server-dist include that file.  Not sure
> why
> >>>>> it is not in server-dist, but it does get copied over in the final
> build.
> >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException:
> >>>>>> org.keycloak.keycloak-server-subsystem:main
> >>>>>>                at
> >>>>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> >>>>>> [jboss-modules.jar:1.5.1.Final]
> >>>>>>                at
> >>>>>>
> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
> >>>>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
> >>>>>>                ... 8 more
> >>>>>>
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/54b2ec69/attachment.html 

From ssilvert at redhat.com  Mon Apr 25 08:14:01 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 25 Apr 2016 08:14:01 -0400
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <CAJgngAfJwfnNmwAO+PW_N=49+FyAU0iYCDAXsaUZh2vTKY4DyQ@mail.gmail.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com> <571D77D6.6080203@redhat.com>
	<571D7D8B.5000304@redhat.com> <571D7E4B.1000706@redhat.com>
	<571E03C1.4050805@redhat.com>
	<CAJgngAfJwfnNmwAO+PW_N=49+FyAU0iYCDAXsaUZh2vTKY4DyQ@mail.gmail.com>
Message-ID: <571E0A09.8020501@redhat.com>

On 4/25/2016 8:03 AM, Stian Thorgersen wrote:
> I've just tried a clean build from 1.9.x sources here and it works 
> fine. What steps do you use to build and run it?
I go to <keycloak-home>/distribution and run:
mvn install -DskipTests

Then if I want to run a development server from server-dist, I run a bat 
file with this:
cd c:\GitHub\keycloak\distribution\server-dist
call mvn clean
sed -i 's/copy-module-artifacts="true"/copy-module-artifacts="false"/' 
/cygdrive/c/GitHub/keycloak/distribution/server-dist/server-provisioning.xml
call mvn compile -DskipTests
sed -i 's/copy-module-artifacts="false"/copy-module-artifacts="true"/' 
/cygdrive/c/GitHub/keycloak/distribution/server-dist/server-provisioning.xml

cd 
c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\standalone\configuration
sed -i 's,"dir": "${jboss.home.dir}/themes","dir": 
"/GitHub/keycloak/themes/src/main/resources/theme",' keycloak-server.json

cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\modules
copy 
c:\GitHub\keycloak\distribution\server-dist\src\main\modules\layers.conf

cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\bin
add-user -u admin -p admin

>
> On 25 April 2016 at 13:47, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 4/24/2016 10:17 PM, Bill Burke wrote:
>     > I'm losing my mind... The unzip has it...
>     I felt the same way when I came across that issue. My personal build
>     script copies it over so that I can still run from server-dist/target.
>     >
>     > On 4/24/2016 10:14 PM, Bill Burke wrote:
>     >> What download are you talking about RH-SSO?
>     >>
>     >> On 4/24/2016 9:50 PM, Stan Silvert wrote:
>     >>> On 4/24/2016 9:49 PM, Bill Burke wrote:
>     >>>> What final build?
>     >>> The one that actually makes it to the download.  It's been
>     like this for
>     >>> a while so it must be working.  I really don't know the details.
>     >>>> On 4/24/2016 9:32 PM, Stan Silvert wrote:
>     >>>>> On 4/24/2016 6:05 PM, Bill Burke wrote:
>     >>>>>> Doesn't boot anymore on 1.9.x build (not sure about
>     master).  Built from
>     >>>>>> clean clone of keycloak repo. I'll look at it tomorrow
>     (Monday) unless
>     >>>>>> the Europeans can do it.
>     >>>>> Are you running from /server-dist/target?  You can't do that
>     any more
>     >>>>> because it doesn't have a /modules/layers.conf file.
>     >>>>>
>     >>>>> I'd be all for having the server-dist include that file. 
>     Not sure why
>     >>>>> it is not in server-dist, but it does get copied over in the
>     final build.
>     >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>     >>>>>> org.keycloak.keycloak-server-subsystem:main
>     >>>>>>                at
>     >>>>>>
>     org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>     >>>>>> [jboss-modules.jar:1.5.1.Final]
>     >>>>>>                at
>     >>>>>>
>     org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>     >>>>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>     >>>>>>                ... 8 more
>     >>>>>>
>     >>>>> _______________________________________________
>     >>>>> keycloak-dev mailing list
>     >>>>> keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >>> _______________________________________________
>     >>> keycloak-dev mailing list
>     >>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Mon Apr 25 08:19:55 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Apr 2016 14:19:55 +0200
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571E0A09.8020501@redhat.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com> <571D77D6.6080203@redhat.com>
	<571D7D8B.5000304@redhat.com> <571D7E4B.1000706@redhat.com>
	<571E03C1.4050805@redhat.com>
	<CAJgngAfJwfnNmwAO+PW_N=49+FyAU0iYCDAXsaUZh2vTKY4DyQ@mail.gmail.com>
	<571E0A09.8020501@redhat.com>
Message-ID: <CAJgngAe4xR9h1Dq-Bum5Qd6zXX3zCQ-mq97xr8OTwMrrzWsrFA@mail.gmail.com>

Not you, I meant what Bill does ;)

On 25 April 2016 at 14:14, Stan Silvert <ssilvert at redhat.com> wrote:

> On 4/25/2016 8:03 AM, Stian Thorgersen wrote:
>
> I've just tried a clean build from 1.9.x sources here and it works fine.
> What steps do you use to build and run it?
>
> I go to <keycloak-home>/distribution and run:
> mvn install -DskipTests
>
> Then if I want to run a development server from server-dist, I run a bat
> file with this:
> cd c:\GitHub\keycloak\distribution\server-dist
> call mvn clean
> sed -i 's/copy-module-artifacts="true"/copy-module-artifacts="false"/'
> /cygdrive/c/GitHub/keycloak/distribution/server-dist/server-provisioning.xml
> call mvn compile -DskipTests
> sed -i 's/copy-module-artifacts="false"/copy-module-artifacts="true"/'
> /cygdrive/c/GitHub/keycloak/distribution/server-dist/server-provisioning.xml
>
> cd
> c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\standalone\configuration
> sed -i 's,"dir": "${jboss.home.dir}/themes","dir":
> "/GitHub/keycloak/themes/src/main/resources/theme",' keycloak-server.json
>
> cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\modules
> copy
> c:\GitHub\keycloak\distribution\server-dist\src\main\modules\layers.conf
>
> cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\bin
> add-user -u admin -p admin
>
>
>
> On 25 April 2016 at 13:47, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 4/24/2016 10:17 PM, Bill Burke wrote:
>> > I'm losing my mind... The unzip has it...
>> I felt the same way when I came across that issue.  My personal build
>> script copies it over so that I can still run from server-dist/target.
>> >
>> > On 4/24/2016 10:14 PM, Bill Burke wrote:
>> >> What download are you talking about RH-SSO?
>> >>
>> >> On 4/24/2016 9:50 PM, Stan Silvert wrote:
>> >>> On 4/24/2016 9:49 PM, Bill Burke wrote:
>> >>>> What final build?
>> >>> The one that actually makes it to the download.  It's been like this
>> for
>> >>> a while so it must be working.  I really don't know the details.
>> >>>> On 4/24/2016 9:32 PM, Stan Silvert wrote:
>> >>>>> On 4/24/2016 6:05 PM, Bill Burke wrote:
>> >>>>>> Doesn't boot anymore on 1.9.x build (not sure about master).
>> Built from
>> >>>>>> clean clone of keycloak repo.  I'll look at it tomorrow (Monday)
>> unless
>> >>>>>> the Europeans can do it.
>> >>>>> Are you running from /server-dist/target?  You can't do that any
>> more
>> >>>>> because it doesn't have a /modules/layers.conf file.
>> >>>>>
>> >>>>> I'd be all for having the server-dist include that file.  Not sure
>> why
>> >>>>> it is not in server-dist, but it does get copied over in the final
>> build.
>> >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>> >>>>>> org.keycloak.keycloak-server-subsystem:main
>> >>>>>>                at
>> >>>>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>> >>>>>> [jboss-modules.jar:1.5.1.Final]
>> >>>>>>                at
>> >>>>>>
>> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>> >>>>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>> >>>>>>                ... 8 more
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> keycloak-dev mailing list
>> >>>>> keycloak-dev at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>> _______________________________________________
>> >>> keycloak-dev mailing list
>> >>> keycloak-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/4efca42a/attachment-0001.html 

From ssilvert at redhat.com  Mon Apr 25 08:22:12 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 25 Apr 2016 08:22:12 -0400
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <CAJgngAe4xR9h1Dq-Bum5Qd6zXX3zCQ-mq97xr8OTwMrrzWsrFA@mail.gmail.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com> <571D77D6.6080203@redhat.com>
	<571D7D8B.5000304@redhat.com> <571D7E4B.1000706@redhat.com>
	<571E03C1.4050805@redhat.com>
	<CAJgngAfJwfnNmwAO+PW_N=49+FyAU0iYCDAXsaUZh2vTKY4DyQ@mail.gmail.com>
	<571E0A09.8020501@redhat.com>
	<CAJgngAe4xR9h1Dq-Bum5Qd6zXX3zCQ-mq97xr8OTwMrrzWsrFA@mail.gmail.com>
Message-ID: <571E0BF4.60509@redhat.com>

On 4/25/2016 8:19 AM, Stian Thorgersen wrote:
> Not you, I meant what Bill does ;)
lol.  For the record, you did reply to me.  :-)

But now I'm intrigued.  How are you building it, Stian?

>
> On 25 April 2016 at 14:14, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 4/25/2016 8:03 AM, Stian Thorgersen wrote:
>>     I've just tried a clean build from 1.9.x sources here and it
>>     works fine. What steps do you use to build and run it?
>     I go to <keycloak-home>/distribution and run:
>     mvn install -DskipTests
>
>     Then if I want to run a development server from server-dist, I run
>     a bat file with this:
>     cd c:\GitHub\keycloak\distribution\server-dist
>     call mvn clean
>     sed -i
>     's/copy-module-artifacts="true"/copy-module-artifacts="false"/'
>     /cygdrive/c/GitHub/keycloak/distribution/server-dist/server-provisioning.xml
>     call mvn compile -DskipTests
>     sed -i
>     's/copy-module-artifacts="false"/copy-module-artifacts="true"/'
>     /cygdrive/c/GitHub/keycloak/distribution/server-dist/server-provisioning.xml
>
>     cd
>     c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\standalone\configuration
>     sed -i 's,"dir": "${jboss.home.dir}/themes","dir":
>     "/GitHub/keycloak/themes/src/main/resources/theme",'
>     keycloak-server.json
>
>     cd
>     c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\modules
>     copy
>     c:\GitHub\keycloak\distribution\server-dist\src\main\modules\layers.conf
>
>
>     cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\bin
>     add-user -u admin -p admin
>
>
>>
>>     On 25 April 2016 at 13:47, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         On 4/24/2016 10:17 PM, Bill Burke wrote:
>>         > I'm losing my mind... The unzip has it...
>>         I felt the same way when I came across that issue.  My
>>         personal build
>>         script copies it over so that I can still run from
>>         server-dist/target.
>>         >
>>         > On 4/24/2016 10:14 PM, Bill Burke wrote:
>>         >> What download are you talking about RH-SSO?
>>         >>
>>         >> On 4/24/2016 9:50 PM, Stan Silvert wrote:
>>         >>> On 4/24/2016 9:49 PM, Bill Burke wrote:
>>         >>>> What final build?
>>         >>> The one that actually makes it to the download.  It's
>>         been like this for
>>         >>> a while so it must be working.  I really don't know the
>>         details.
>>         >>>> On 4/24/2016 9:32 PM, Stan Silvert wrote:
>>         >>>>> On 4/24/2016 6:05 PM, Bill Burke wrote:
>>         >>>>>> Doesn't boot anymore on 1.9.x build (not sure about
>>         master).  Built from
>>         >>>>>> clean clone of keycloak repo.  I'll look at it
>>         tomorrow (Monday) unless
>>         >>>>>> the Europeans can do it.
>>         >>>>> Are you running from /server-dist/target?  You can't do
>>         that any more
>>         >>>>> because it doesn't have a /modules/layers.conf file.
>>         >>>>>
>>         >>>>> I'd be all for having the server-dist include that
>>         file.  Not sure why
>>         >>>>> it is not in server-dist, but it does get copied over
>>         in the final build.
>>         >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>>         >>>>>> org.keycloak.keycloak-server-subsystem:main
>>         >>>>>>                at
>>         >>>>>>
>>         org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>>         >>>>>> [jboss-modules.jar:1.5.1.Final]
>>         >>>>>>                at
>>         >>>>>>
>>         org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>>         >>>>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>>         >>>>>> ... 8 more
>>         >>>>>>
>>         >>>>> _______________________________________________
>>         >>>>> keycloak-dev mailing list
>>         >>>>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         >>> _______________________________________________
>>         >>> keycloak-dev mailing list
>>         >>> keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>

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

From sthorger at redhat.com  Mon Apr 25 08:28:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Apr 2016 14:28:01 +0200
Subject: [keycloak-dev] server distro BROKEN
In-Reply-To: <571E0BF4.60509@redhat.com>
References: <571D4340.6070008@redhat.com> <571D73AB.3020702@redhat.com>
	<571D77BB.1030005@redhat.com> <571D77D6.6080203@redhat.com>
	<571D7D8B.5000304@redhat.com> <571D7E4B.1000706@redhat.com>
	<571E03C1.4050805@redhat.com>
	<CAJgngAfJwfnNmwAO+PW_N=49+FyAU0iYCDAXsaUZh2vTKY4DyQ@mail.gmail.com>
	<571E0A09.8020501@redhat.com>
	<CAJgngAe4xR9h1Dq-Bum5Qd6zXX3zCQ-mq97xr8OTwMrrzWsrFA@mail.gmail.com>
	<571E0BF4.60509@redhat.com>
Message-ID: <CAJgngAfvWLEkgCDNA0E8afSsZ26PYU-D6dvERT5Xk6fy8ViAmw@mail.gmail.com>

mvn clean install -DskipTests -Pdistribution
kc-server -s

kc-server unzips it from ~/.m2/repository to a special location on my box.
It also has other clever tricks like installing overlay on WF/EAP7,
enabling debug, etc, etc..

On 25 April 2016 at 14:22, Stan Silvert <ssilvert at redhat.com> wrote:

> On 4/25/2016 8:19 AM, Stian Thorgersen wrote:
>
> Not you, I meant what Bill does ;)
>
> lol.  For the record, you did reply to me.  :-)
>
> But now I'm intrigued.  How are you building it, Stian?
>
>
>
> On 25 April 2016 at 14:14, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 4/25/2016 8:03 AM, Stian Thorgersen wrote:
>>
>> I've just tried a clean build from 1.9.x sources here and it works fine.
>> What steps do you use to build and run it?
>>
>> I go to <keycloak-home>/distribution and run:
>> mvn install -DskipTests
>>
>> Then if I want to run a development server from server-dist, I run a bat
>> file with this:
>> cd c:\GitHub\keycloak\distribution\server-dist
>> call mvn clean
>> sed -i 's/copy-module-artifacts="true"/copy-module-artifacts="false"/'
>> /cygdrive/c/GitHub/keycloak/distribution/server-dist/server-provisioning.xml
>> call mvn compile -DskipTests
>> sed -i 's/copy-module-artifacts="false"/copy-module-artifacts="true"/'
>> /cygdrive/c/GitHub/keycloak/distribution/server-dist/server-provisioning.xml
>>
>> cd
>> c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\standalone\configuration
>> sed -i 's,"dir": "${jboss.home.dir}/themes","dir":
>> "/GitHub/keycloak/themes/src/main/resources/theme",' keycloak-server.json
>>
>> cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\modules
>> copy
>> c:\GitHub\keycloak\distribution\server-dist\src\main\modules\layers.conf
>>
>> cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\bin
>> add-user -u admin -p admin
>>
>>
>>
>> On 25 April 2016 at 13:47, Stan Silvert <ssilvert at redhat.com> wrote:
>>
>>> On 4/24/2016 10:17 PM, Bill Burke wrote:
>>> > I'm losing my mind... The unzip has it...
>>> I felt the same way when I came across that issue.  My personal build
>>> script copies it over so that I can still run from server-dist/target.
>>> >
>>> > On 4/24/2016 10:14 PM, Bill Burke wrote:
>>> >> What download are you talking about RH-SSO?
>>> >>
>>> >> On 4/24/2016 9:50 PM, Stan Silvert wrote:
>>> >>> On 4/24/2016 9:49 PM, Bill Burke wrote:
>>> >>>> What final build?
>>> >>> The one that actually makes it to the download.  It's been like this
>>> for
>>> >>> a while so it must be working.  I really don't know the details.
>>> >>>> On 4/24/2016 9:32 PM, Stan Silvert wrote:
>>> >>>>> On 4/24/2016 6:05 PM, Bill Burke wrote:
>>> >>>>>> Doesn't boot anymore on 1.9.x build (not sure about master).
>>> Built from
>>> >>>>>> clean clone of keycloak repo.  I'll look at it tomorrow (Monday)
>>> unless
>>> >>>>>> the Europeans can do it.
>>> >>>>> Are you running from /server-dist/target?  You can't do that any
>>> more
>>> >>>>> because it doesn't have a /modules/layers.conf file.
>>> >>>>>
>>> >>>>> I'd be all for having the server-dist include that file.  Not sure
>>> why
>>> >>>>> it is not in server-dist, but it does get copied over in the final
>>> build.
>>> >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException:
>>> >>>>>> org.keycloak.keycloak-server-subsystem:main
>>> >>>>>>                at
>>> >>>>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
>>> >>>>>> [jboss-modules.jar:1.5.1.Final]
>>> >>>>>>                at
>>> >>>>>>
>>> org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:178)
>>> >>>>>> [wildfly-controller-2.0.10.Final.jar:2.0.10.Final]
>>> >>>>>>                ... 8 more
>>> >>>>>>
>>> >>>>> _______________________________________________
>>> >>>>> keycloak-dev mailing list
>>> >>>>> keycloak-dev at lists.jboss.org
>>> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>> _______________________________________________
>>> >>> keycloak-dev mailing list
>>> >>> keycloak-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/f00433bf/attachment-0001.html 

From mposolda at redhat.com  Mon Apr 25 08:30:46 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Apr 2016 14:30:46 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571E06A4.60505@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com> <571D1771.3020405@redhat.com>
	<571D75D1.6020904@redhat.com>
	<CAJgngAfR+XsrCen-xDJe9Ajv0WhYC7RjJuA9zUfLZpukxBcQRQ@mail.gmail.com>
	<571DD946.5010101@redhat.com>
	<CAJgngAezaW7pqAZ=70vdSi_-C4g6FVJxUfzL3mmGyQj9Uy4hbQ@mail.gmail.com>
	<571E06A4.60505@redhat.com>
Message-ID: <571E0DF6.1060805@redhat.com>

+1

On 25/04/16 13:59, Stan Silvert wrote:
> +1.  That's the "prettier" UI option I was talking about.
>
> On 4/25/2016 4:56 AM, Stian Thorgersen wrote:
>> +1 To what Marek is proposing
>>
>> I'd suggest a slightly more mellow tone though. Rather than the 
>> current message (which is a bit rubbish):
>>
>>    Added 'k' to 
>> '/home/st/tmp/keycloak-1.9.2.Final/standalone/configuration/keycloak-add-user.json', 
>> restart server to load user
>>
>> We could do:
>>
>>   Keycloak admin user added, please restart server to make the user 
>> available. To add user for jboss-cli please run "add-user" with 
>> "--container" option.
>>
>> Other improvements we could do are:
>>
>> * "--container" description should be "Add user to jboss-cli. For 
>> usage use '--container --help'"
>> * When add-user is run without options it currently says 'Option: 
>> -u.. is required' it should instead display help text (--help) and 
>> the help text should have a paragraph on the bottom stating how the 
>> user is added, that the server needs to be reloaded and also how to 
>> add a user to jboss-cli.
>>
>> I'm happy to incorporate the above changes if that's what we agree on.
>>
>> On 25 April 2016 at 10:45, Marek Posolda <mposolda at redhat.com 
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>     On 25/04/16 09:35, Stian Thorgersen wrote:
>>>     Seems like the majority (that being everyone besides me) would
>>>     like to have the script renamed. So let's go for it, but first I
>>>     have two questions:
>>     Btv. I didn't suggest to rename, but keep as is. But always when
>>     people run "add-user.sh" without "--container", there will be be
>>     a big warning similar to:
>>
>>     "You are adding Keycloak admin, but not Wildfly admin!!! If you
>>     want to add Wildfly admin use the option --container"
>>
>>     This should solve both your (a) and (b) and remove most of
>>     confusions IMO. And in the future version, when keycloak and
>>     wildfly admin will be same thing, we can still use same
>>     "add-user.sh" script without need to rename, remove or add any
>>     new script. We will just remove the warning and possibly support
>>     for "--container" option.
>>
>>
>>     Marek
>>
>>
>>>
>>>     a) What should it be called (it can't be add-user-keycloak.sh as
>>>     then it wouldn't make sense in product)? add-user-sso.sh is an
>>>     idea, but is it clear that's adding "Keycloak admin console" users
>>>     b) Will we not get a bunch of people asking "I added a user with
>>>     add-user, but still can't login to Keycloak admin console"? Do
>>>     we have a solution for that?
>>>
>>>     On 25 April 2016 at 03:41, Stan Silvert <ssilvert at redhat.com
>>>     <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>
>>>         On 4/24/2016 2:58 PM, Bill Burke wrote:
>>>         > Completely different.  standalone.sh and domain.sh are
>>>         completely new
>>>         > run.sh variants and run.sh disappeared.
>>>         Nope.  If there was no domain.sh we would have kept run.sh.
>>>         standalone.sh does exactly the same thing run.sh used to do.
>>>         Furthermore, run.sh didn't disappear.  It just prints a
>>>         helpful message.
>>>
>>>         The situation here is exactly the same.  If there was no
>>>         "keycloak"
>>>         add-user we would have kept the old one.
>>>
>>>         Bill, I agree that the current situation is confusing. 
>>>         Stian, I agree
>>>         that having both "add-user.sh" and "add-user-keycloak.sh" is
>>>         also confusing.
>>>
>>>         The WildFly solution isn't pretty, but at least it isn't
>>>         confusing.
>>>
>>>         I suppose you could make the whole thing prettier by
>>>         slapping some extra
>>>         UI into the unified version.  Let it prompt the user for
>>>         what he really
>>>         wants to do, etc., etc.
>>>         >
>>>         > add-user.sh is the same script as the old.  and you've
>>>         already had two
>>>         > Red Hat people scratching their heads wondering what
>>>         happened to
>>>         > add-user.sh.
>>>         Were you including me?  I complained about this several
>>>         weeks ago, so
>>>         perhaps you can make that three Red Hat people.  I agree
>>>         that it's a
>>>         problem.
>>>         >
>>>         > On 4/23/2016 3:04 PM, Stan Silvert wrote:
>>>         >> We had the same kind of problem in WildFly a few years
>>>         ago.  Everyone
>>>         >> was used to starting the server with run.sh.  But we
>>>         needed to change
>>>         >> that to differentiate between standalone.sh and
>>>         domain.sh.  So we made
>>>         >> run.bat just print out a "This is deprecated.  Here is
>>>         what you need to
>>>         >> do...." message.
>>>         >>
>>>         >> It's not a perfect solution, but we could do the same
>>>         thing with
>>>         >> add-user.sh and tell them to use either
>>>         add-user-keycloak.sh or
>>>         >> add-user-eap.sh.  At least you wouldn't get any support
>>>         questions.
>>>         >>
>>>         >> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>>>         >>> Hello!
>>>         >>>
>>>         >>> As a new member of keycloak QA team I recently had to
>>>         set up some
>>>         >>> clustering with domain mode.
>>>         >>> I was really confused when add-user.sh did not add user
>>>         to jboss but
>>>         >>> rather created the keycloak-add-user.json.
>>>         >>> The worst thing was that I couldn't find any docs on
>>>         adding user to
>>>         >>> underlying eap at all.
>>>         >>> Had to read the add-user.sh itself to find out what was
>>>         happening.
>>>         >>> Even if it remains as it is, it really should be at
>>>         least mentioned in
>>>         >>> the docs :)
>>>         >>>
>>>         >>> Have a nice day!
>>>         >>> Ilya Rum.
>>>         >>>
>>>         >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>>>         >>>> Do you care about usability at all?  Not everything can
>>>         fit into nice little
>>>         >>>> boxes all the time. This is going to be extremely
>>>         confusing for users.  I
>>>         >>>> ran into it myself as I thought the jboss add-user.sh
>>>         script was overwritten
>>>         >>>> by our distribution script by mistake.  *OF COURSE* we
>>>         should have a
>>>         >>>> separate add-user.sh script. Even when, hopefully,
>>>         JBoss can delegate to
>>>         >>>> Keycloak in maybe 7.1. If we are going to leverage the
>>>         JBoss platform, and
>>>         >>>> this means the JBoss documentation too, every
>>>         management function that
>>>         >>>> exists in JBoss should be available in Keycloak and
>>>         *WORK THE SAME WAY*.  If
>>>         >>>> we don't change this, we're going to get a ton of
>>>         support questions that
>>>         >>>> say: "Why doesn't add-user.sh work?"
>>>         >>>>
>>>         >>>>
>>>         >>>>
>>>         >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>>         >>>>> In the future we need to secure the underlying WildFly
>>>         with rhsso. In
>>>         >>>>> which case our add-user will add users for both
>>>         Keycloak and WildFly/EAP.
>>>         >>>>>
>>>         >>>>> IMO there's going to be confusion until the above is
>>>         solved no matter what
>>>         >>>>> we do. We'll need to document this whichever way we do
>>>         it. Options are
>>>         >>>>> stay with what we have or rename our script. My vote
>>>         goes to keep as is
>>>         >>>>> and document it. Then hopefully by 7.1 we can secure
>>>         the WildFly bits so
>>>         >>>>> the problem goes away. With the other option (rename
>>>         ours) there will be a
>>>         >>>>> problem once WildFly bits are secured by Keycloak as
>>>         now the wf add-user
>>>         >>>>> script should no longer be used and completely removed
>>>         at which point we
>>>         >>>>> should then rename it back. So in the long run
>>>         sticking with how it is
>>>         >>>>> today is ideal. It's also way to late making changes
>>>         now. BTW this has
>>>         >>>>> been around for months.
>>>         >>>>>
>>>         >>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke at redhat.com
>>>         <mailto:bburke at redhat.com>
>>>         >>>>> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>>
>>>         wrote:
>>>         >>>>>
>>>         >>>>>
>>>         >>>>>
>>>         >>>>>       On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>>         >>>>>       > That's the question...
>>>         >>>>>       >
>>>         >>>>>       > For server distribution, we also have our
>>>         stuff ( keycloak
>>>         >>>>>       subsystem,
>>>         >>>>>       > datasource, infinispan etc) directly declared in
>>>         >>>>>  "standalone.xml". On
>>>         >>>>>       > the other hand, for overlay distribution, we
>>>         don't want to directly
>>>         >>>>>       > update default "standalone.xml", so we are
>>>         adding our own
>>>         >>>>>       > "standalone-keycloak.xml". Isn't it quite
>>>         similar thing?
>>>         >>>>>       >
>>>         >>>>>
>>>         >>>>>       Product will not have the overlay distribution.
>>>         >>>>>
>>>         >>>>>       > We can do the same for overlay and server
>>>         distribution, so never
>>>         >>>>>       edit
>>>         >>>>>       > default wildfly files ( standalone.xml ,
>>>         add-user.sh), but
>>>         >>>>>       always use
>>>         >>>>>       > our own versions with "-keycloak" suffix.
>>>         Advantage is more
>>>         >>>>>       > consistent. However people will need to always
>>>         start keycloak server
>>>         >>>>>       > with "./standalone.sh -c
>>>         standalone-keycloak.xml" then. Doesn't it
>>>         >>>>>       > sucks from the usability perspective?
>>>         >>>>>       >
>>>         >>>>>
>>>         >>>>>       The overlay exists because we can't distribute
>>>         EAP within community.
>>>         >>>>>       Keycloak should be run as a separate server, so,
>>>         IMO, -keycloak.xml
>>>         >>>>>       files should go away and overwrite standalone.xml,
>>>         >>>>>  standalone-ha.xml and
>>>         >>>>>       domain.xml
>>>         >>>>>
>>>         >>>>>       > I honestly don't know what's the best way
>>>         regarding usability. AFAIK
>>>         >>>>>       > this was decided on mailing lists couple of
>>>         months ago, but don't
>>>         >>>>>       > remember the exact threads...:/
>>>         >>>>>       >
>>>         >>>>>
>>>         >>>>>       I'm pretty adamant about this.  There will be a
>>>         huge amount of
>>>         >>>>>       confusion
>>>         >>>>>       if we don't make this separation.  Wildfly/JBoss
>>>         and Keycloak are hard
>>>         >>>>>       enough to configure as it is.
>>>         >>>>>
>>>         >>>>>
>>>         >>>>>       --
>>>         >>>>>       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>
>>>         <mailto:keycloak-dev at lists.jboss.org
>>>         <mailto: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
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>         >>> _______________________________________________
>>>         >>> keycloak-dev mailing list
>>>         >>> keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>         >> _______________________________________________
>>>         >> keycloak-dev mailing list
>>>         >> keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     keycloak-dev mailing list
>>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>

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

From roelof.naude at gmail.com  Mon Apr 25 10:02:18 2016
From: roelof.naude at gmail.com (Roelof Naude)
Date: Mon, 25 Apr 2016 16:02:18 +0200
Subject: [keycloak-dev] argon2 password hashing
Message-ID: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>

hi,

a client has requested the use of the argon2 [1, 2] password hashing
scheme. this can easily be added as an external provider. we do however
require custom password policies, e.g. memory / parallelism cost as well as
salt length. AFAIK there is no way to provide policy extensions using a
provider interface?

would argon2 be a worthwhile contribution?

regards
roelof.

[1] https://github.com/P-H-C/phc-winner-argon2
[2] https://github.com/phxql/argon2-jvm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/6769a415/attachment.html 

From bruno at abstractj.org  Mon Apr 25 10:42:49 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 25 Apr 2016 11:42:49 -0300
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>
Message-ID: <20160425144249.GB29202@abstractj.org>

I believe we don't have an SPI for this, yet. See: https://issues.jboss.org/browse/KEYCLOAK-2824.

IMO, Argon2 is completely new and aside from the bindings, we don't have
a Java implementation, yet for this. I'm not sure if is a good idea to
introduce C to the codebase, but totally doable to have an SPI for
policies.

On 2016-04-25, Roelof Naude wrote:
> hi,
>
> a client has requested the use of the argon2 [1, 2] password hashing
> scheme. this can easily be added as an external provider. we do however
> require custom password policies, e.g. memory / parallelism cost as well as
> salt length. AFAIK there is no way to provide policy extensions using a
> provider interface?
>
> would argon2 be a worthwhile contribution?
>
> regards
> roelof.
>
> [1] https://github.com/P-H-C/phc-winner-argon2
> [2] https://github.com/phxql/argon2-jvm

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


--

abstractj
PGP: 0x84DC9914

From sthorger at redhat.com  Mon Apr 25 11:30:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Apr 2016 17:30:37 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <20160425144249.GB29202@abstractj.org>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>
	<20160425144249.GB29202@abstractj.org>
Message-ID: <CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>

We an to introduce a password policy spi soon, but for now you're stuck
with the built-in policies.
On 25 Apr 2016 16:43, "Bruno Oliveira" <bruno at abstractj.org> wrote:

> I believe we don't have an SPI for this, yet. See:
> https://issues.jboss.org/browse/KEYCLOAK-2824.
>
> IMO, Argon2 is completely new and aside from the bindings, we don't have
> a Java implementation, yet for this. I'm not sure if is a good idea to
> introduce C to the codebase, but totally doable to have an SPI for
> policies.
>
> On 2016-04-25, Roelof Naude wrote:
> > hi,
> >
> > a client has requested the use of the argon2 [1, 2] password hashing
> > scheme. this can easily be added as an external provider. we do however
> > require custom password policies, e.g. memory / parallelism cost as well
> as
> > salt length. AFAIK there is no way to provide policy extensions using a
> > provider interface?
> >
> > would argon2 be a worthwhile contribution?
> >
> > regards
> > roelof.
> >
> > [1] https://github.com/P-H-C/phc-winner-argon2
> > [2] https://github.com/phxql/argon2-jvm
>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/4522ea4d/attachment.html 

From roelof.naude at gmail.com  Mon Apr 25 12:36:42 2016
From: roelof.naude at gmail.com (Roelof Naude)
Date: Mon, 25 Apr 2016 18:36:42 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>
	<20160425144249.GB29202@abstractj.org>
	<CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>
Message-ID: <CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>

thank you all for the quick response.

do you guys have a basic idea on how to approach the policy spi? we are
more than willing to help out to get it done.

maintaining a fork is maybe an option to resolve the immediate need, but
would prefer to keep things upstream as much as possible.

On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> We an to introduce a password policy spi soon, but for now you're stuck
> with the built-in policies.
> On 25 Apr 2016 16:43, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>
>> I believe we don't have an SPI for this, yet. See:
>> https://issues.jboss.org/browse/KEYCLOAK-2824.
>>
>> IMO, Argon2 is completely new and aside from the bindings, we don't have
>> a Java implementation, yet for this. I'm not sure if is a good idea to
>> introduce C to the codebase, but totally doable to have an SPI for
>> policies.
>>
>> On 2016-04-25, Roelof Naude wrote:
>> > hi,
>> >
>> > a client has requested the use of the argon2 [1, 2] password hashing
>> > scheme. this can easily be added as an external provider. we do however
>> > require custom password policies, e.g. memory / parallelism cost as
>> well as
>> > salt length. AFAIK there is no way to provide policy extensions using a
>> > provider interface?
>> >
>> > would argon2 be a worthwhile contribution?
>> >
>> > regards
>> > roelof.
>> >
>> > [1] https://github.com/P-H-C/phc-winner-argon2
>> > [2] https://github.com/phxql/argon2-jvm
>>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/34deb757/attachment.html 

From 00hf11 at gmail.com  Mon Apr 25 13:43:29 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Mon, 25 Apr 2016 14:43:29 -0300
Subject: [keycloak-dev] Some questions about refresh tokens
In-Reply-To: <CABv=XZVfBYTzt-zf8UCo_B8DA=dtw8+ooRSdwyEidAaiZ6jMsA@mail.gmail.com>
References: <CABv=XZVfBYTzt-zf8UCo_B8DA=dtw8+ooRSdwyEidAaiZ6jMsA@mail.gmail.com>
Message-ID: <CABv=XZWvUHxMof5pce7GSwnEzV1fJt+VHiPs+4fVLwtOGkyxDQ@mail.gmail.com>

Hi,

Doing exact the same as:
http://keycloak.github.io/docs/userguide/keycloak-server/html_single/index.html#direct-access-grants


I'm getting the same value for  "access_token" and "refresh_token"

Is needed configure something to get the same behavior described on docs ?

Thanks !


On Fri, Apr 22, 2016 at 11:06 AM, Helio Frota <00hf11 at gmail.com> wrote:

> Hi,
>
> I'm trying to use this code to refresh a token :
>
>
> https://github.com/keycloak/keycloak-nodejs-auth-utils/blob/master/lib/grant-manager.js#L207
>
> Also noticed that endpoint changed ^
>
> So after to read :
>
>
> https://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html
>
> I modified the url but I can not get a refreshed token
>
> Also, following the example :
>
>
> https://github.com/keycloak/keycloak/blob/5c98b8c6ae7052b2d906156d8fc212ccd9dfd57d/docbook/auth-server-docs/reference/en/en-US/modules/direct-access.xml#L71-L74
>
> I noticed that access_token is the same as refresh_token.
>
> Questions:
>
> 1. Still possible to refresh token ?
> 2. If yes, how to do it ? [url, parameters... or configuration on Keycloak
> ?]
>
> Thanks
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/9744da67/attachment-0001.html 

From sthorger at redhat.com  Wed Apr 27 03:29:53 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Apr 2016 09:29:53 +0200
Subject: [keycloak-dev] add-user.sh overwrites wildfly one
In-Reply-To: <571E0DF6.1060805@redhat.com>
References: <571A4733.7000606@redhat.com> <571A49B8.4040601@redhat.com>
	<571A6019.4000605@redhat.com> <571A820D.8050705@redhat.com>
	<571A85FF.3040900@redhat.com>
	<CAJgngAdKXKOsm60uXM9D5E3TYhhEgOE7ZXbgC6Fgxb1UnV=y0Q@mail.gmail.com>
	<571B6F0F.6030702@redhat.com> <20160423130659.GA5385@wv-toplap>
	<571BC732.7030108@redhat.com> <571D1771.3020405@redhat.com>
	<571D75D1.6020904@redhat.com>
	<CAJgngAfR+XsrCen-xDJe9Ajv0WhYC7RjJuA9zUfLZpukxBcQRQ@mail.gmail.com>
	<571DD946.5010101@redhat.com>
	<CAJgngAezaW7pqAZ=70vdSi_-C4g6FVJxUfzL3mmGyQj9Uy4hbQ@mail.gmail.com>
	<571E06A4.60505@redhat.com> <571E0DF6.1060805@redhat.com>
Message-ID: <CAJgngAd1ww32uN-P6p7A16LsAoxVJGBhhK35H1jgdgBDtQiV+g@mail.gmail.com>

Unless someone has very strong arguments against it we're going to rename
the script to "add-user-keycloak". Main reason is that WildFly
documentation refer to the "add-user" script throughout their
documentation, so the simplest is to have our own rather than override what
they have. We'll also remove the '--container' argument. If anyone was
wondering 'add-user-keycloak' is confirmed as ok for product.

On 25 April 2016 at 14:30, Marek Posolda <mposolda at redhat.com> wrote:

> +1
>
>
> On 25/04/16 13:59, Stan Silvert wrote:
>
> +1.  That's the "prettier" UI option I was talking about.
>
> On 4/25/2016 4:56 AM, Stian Thorgersen wrote:
>
> +1 To what Marek is proposing
>
> I'd suggest a slightly more mellow tone though. Rather than the current
> message (which is a bit rubbish):
>
>    Added 'k' to
> '/home/st/tmp/keycloak-1.9.2.Final/standalone/configuration/keycloak-add-user.json',
> restart server to load user
>
> We could do:
>
>   Keycloak admin user added, please restart server to make the user
> available. To add user for jboss-cli please run "add-user" with
> "--container" option.
>
> Other improvements we could do are:
>
> * "--container" description should be "Add user to jboss-cli. For usage
> use '--container --help'"
> * When add-user is run without options it currently says 'Option: -u.. is
> required' it should instead display help text (--help) and the help text
> should have a paragraph on the bottom stating how the user is added, that
> the server needs to be reloaded and also how to add a user to jboss-cli.
>
> I'm happy to incorporate the above changes if that's what we agree on.
>
> On 25 April 2016 at 10:45, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 25/04/16 09:35, Stian Thorgersen wrote:
>>
>> Seems like the majority (that being everyone besides me) would like to
>> have the script renamed. So let's go for it, but first I have two questions:
>>
>> Btv. I didn't suggest to rename, but keep as is. But always when people
>> run "add-user.sh" without "--container", there will be be a big warning
>> similar to:
>>
>> "You are adding Keycloak admin, but not Wildfly admin!!! If you want to
>> add Wildfly admin use the option --container"
>>
>> This should solve both your (a) and (b) and remove most of confusions
>> IMO. And in the future version, when keycloak and wildfly admin will be
>> same thing, we can still use same "add-user.sh" script without need to
>> rename, remove or add any new script. We will just remove the warning and
>> possibly support for "--container" option.
>>
>>
>> Marek
>>
>>
>>
>> a) What should it be called (it can't be add-user-keycloak.sh as then it
>> wouldn't make sense in product)? add-user-sso.sh is an idea, but is it
>> clear that's adding "Keycloak admin console" users
>> b) Will we not get a bunch of people asking "I added a user with
>> add-user, but still can't login to Keycloak admin console"? Do we have a
>> solution for that?
>>
>> On 25 April 2016 at 03:41, Stan Silvert < <ssilvert at redhat.com>
>> ssilvert at redhat.com> wrote:
>>
>>>
>>> On 4/24/2016 2:58 PM, Bill Burke wrote:
>>> > Completely different.  standalone.sh and domain.sh are completely new
>>> > run.sh variants and run.sh disappeared.
>>> Nope.  If there was no domain.sh we would have kept run.sh.
>>> standalone.sh does exactly the same thing run.sh used to do.
>>> Furthermore, run.sh didn't disappear.  It just prints a helpful message.
>>>
>>> The situation here is exactly the same.  If there was no "keycloak"
>>> add-user we would have kept the old one.
>>>
>>> Bill, I agree that the current situation is confusing.  Stian, I agree
>>> that having both "add-user.sh" and "add-user-keycloak.sh" is also
>>> confusing.
>>>
>>> The WildFly solution isn't pretty, but at least it isn't confusing.
>>>
>>> I suppose you could make the whole thing prettier by slapping some extra
>>> UI into the unified version.  Let it prompt the user for what he really
>>> wants to do, etc., etc.
>>> >
>>> > add-user.sh is the same script as the old.  and you've already had two
>>> > Red Hat people scratching their heads wondering what happened to
>>> > add-user.sh.
>>> Were you including me?  I complained about this several weeks ago, so
>>> perhaps you can make that three Red Hat people.  I agree that it's a
>>> problem.
>>> >
>>> > On 4/23/2016 3:04 PM, Stan Silvert wrote:
>>> >> We had the same kind of problem in WildFly a few years ago.  Everyone
>>> >> was used to starting the server with run.sh.  But we needed to change
>>> >> that to differentiate between standalone.sh and domain.sh.  So we made
>>> >> run.bat just print out a "This is deprecated.  Here is what you need
>>> to
>>> >> do...." message.
>>> >>
>>> >> It's not a perfect solution, but we could do the same thing with
>>> >> add-user.sh and tell them to use either add-user-keycloak.sh or
>>> >> add-user-eap.sh.  At least you wouldn't get any support questions.
>>> >>
>>> >> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>>> >>> Hello!
>>> >>>
>>> >>> As a new member of keycloak QA team I recently had to set up some
>>> >>> clustering with domain mode.
>>> >>> I was really confused when add-user.sh did not add user to jboss but
>>> >>> rather created the keycloak-add-user.json.
>>> >>> The worst thing was that I couldn't find any docs on adding user to
>>> >>> underlying eap at all.
>>> >>> Had to read the add-user.sh itself to find out what was happening.
>>> >>> Even if it remains as it is, it really should be at least mentioned
>>> in
>>> >>> the docs :)
>>> >>>
>>> >>> Have a nice day!
>>> >>> Ilya Rum.
>>> >>>
>>> >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>>> >>>> Do you care about usability at all?  Not everything can fit into
>>> nice little
>>> >>>> boxes all the time.  This is going to be extremely confusing for
>>> users.  I
>>> >>>> ran into it myself as I thought the jboss add-user.sh script was
>>> overwritten
>>> >>>> by our distribution script by mistake.  *OF COURSE* we should have a
>>> >>>> separate add-user.sh script. Even when, hopefully, JBoss can
>>> delegate to
>>> >>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss
>>> platform, and
>>> >>>> this means the JBoss documentation too, every management function
>>> that
>>> >>>> exists in JBoss should be available in Keycloak and *WORK THE SAME
>>> WAY*.  If
>>> >>>> we don't change this, we're going to get a ton of support questions
>>> that
>>> >>>> say: "Why doesn't add-user.sh work?"
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>> >>>>> In the future we need to secure the underlying WildFly with rhsso.
>>> In
>>> >>>>> which case our add-user will add users for both Keycloak and
>>> WildFly/EAP.
>>> >>>>>
>>> >>>>> IMO there's going to be confusion until the above is solved no
>>> matter what
>>> >>>>> we do. We'll need to document this whichever way we do it. Options
>>> are
>>> >>>>> stay with what we have or rename our script. My vote goes to keep
>>> as is
>>> >>>>> and document it. Then hopefully by 7.1 we can secure the WildFly
>>> bits so
>>> >>>>> the problem goes away. With the other option (rename ours) there
>>> will be a
>>> >>>>> problem once WildFly bits are secured by Keycloak as now the wf
>>> add-user
>>> >>>>> script should no longer be used and completely removed at which
>>> point we
>>> >>>>> should then rename it back. So in the long run sticking with how
>>> it is
>>> >>>>> today is ideal. It's also way to late making changes now. BTW this
>>> has
>>> >>>>> been around for months.
>>> >>>>>
>>> >>>>> On 22 Apr 2016 22:14, "Bill Burke" < <bburke at redhat.com>
>>> bburke at redhat.com
>>> >>>>> <mailto: <bburke at redhat.com>bburke at redhat.com>> wrote:
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>       On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>> >>>>>       > That's the question...
>>> >>>>>       >
>>> >>>>>       > For server distribution, we also have our stuff ( keycloak
>>> >>>>>       subsystem,
>>> >>>>>       > datasource, infinispan etc) directly declared in
>>> >>>>>       "standalone.xml". On
>>> >>>>>       > the other hand, for overlay distribution, we don't want to
>>> directly
>>> >>>>>       > update default "standalone.xml", so we are adding our own
>>> >>>>>       > "standalone-keycloak.xml". Isn't it quite similar thing?
>>> >>>>>       >
>>> >>>>>
>>> >>>>>       Product will not have the overlay distribution.
>>> >>>>>
>>> >>>>>       > We can do the same for overlay and server distribution, so
>>> never
>>> >>>>>       edit
>>> >>>>>       > default wildfly files ( standalone.xml , add-user.sh), but
>>> >>>>>       always use
>>> >>>>>       > our own versions with "-keycloak" suffix. Advantage is more
>>> >>>>>       > consistent. However people will need to always start
>>> keycloak server
>>> >>>>>       > with "./standalone.sh -c standalone-keycloak.xml" then.
>>> Doesn't it
>>> >>>>>       > sucks from the usability perspective?
>>> >>>>>       >
>>> >>>>>
>>> >>>>>       The overlay exists because we can't distribute EAP within
>>> community.
>>> >>>>>       Keycloak should be run as a separate server, so, IMO,
>>> -keycloak.xml
>>> >>>>>       files should go away and overwrite standalone.xml,
>>> >>>>>       standalone-ha.xml and
>>> >>>>>       domain.xml
>>> >>>>>
>>> >>>>>       > I honestly don't know what's the best way regarding
>>> usability. AFAIK
>>> >>>>>       > this was decided on mailing lists couple of months ago,
>>> but don't
>>> >>>>>       > remember the exact threads...:/
>>> >>>>>       >
>>> >>>>>
>>> >>>>>       I'm pretty adamant about this.  There will be a huge amount
>>> of
>>> >>>>>       confusion
>>> >>>>>       if we don't make this separation.  Wildfly/JBoss and
>>> Keycloak are hard
>>> >>>>>       enough to configure as it is.
>>> >>>>>
>>> >>>>>
>>> >>>>>       --
>>> >>>>>       Bill Burke
>>> >>>>>       JBoss, a division of Red Hat
>>> >>>>>        <http://bill.burkecentral.com>http://bill.burkecentral.com
>>> >>>>>
>>> >>>>>       _______________________________________________
>>> >>>>>       keycloak-dev mailing list
>>> >>>>>        <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> >>>>>        <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>>>>
>>> >>>> --
>>> >>>> Bill Burke
>>> >>>> JBoss, a division of Red Hat
>>> >>>> <http://bill.burkecentral.com>http://bill.burkecentral.com
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> keycloak-dev mailing list
>>> >>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>> >>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>> _______________________________________________
>>> >>> keycloak-dev mailing list
>>> >>> keycloak-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >> _______________________________________________
>>> >> keycloak-dev mailing list
>>> >> keycloak-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160427/36af5415/attachment-0001.html 

From lholmqui at redhat.com  Wed Apr 27 10:54:10 2016
From: lholmqui at redhat.com (Luke Holmquist)
Date: Wed, 27 Apr 2016 10:54:10 -0400
Subject: [keycloak-dev] Node.js REST admin client
Message-ID: <CALD3Fd3dqc8BFp+OKx2gP7vxr58DV2y2HrZkpOoUjLELJMM_Sw@mail.gmail.com>

Hello,

So i've just recently published a 0.1.0 version of a node.js admin REST
client i've been working on

https://www.npmjs.com/package/keycloak-admin-client

currently it only has the CRUD endpoints for Realms and Users implemented,
but i'm following the REST API docs to get more functionality in.


feel free to play with it


-Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160427/3a98051a/attachment.html 

From 00hf11 at gmail.com  Wed Apr 27 16:00:18 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Wed, 27 Apr 2016 17:00:18 -0300
Subject: [keycloak-dev] Node.js REST admin client
In-Reply-To: <CALD3Fd3dqc8BFp+OKx2gP7vxr58DV2y2HrZkpOoUjLELJMM_Sw@mail.gmail.com>
References: <CALD3Fd3dqc8BFp+OKx2gP7vxr58DV2y2HrZkpOoUjLELJMM_Sw@mail.gmail.com>
Message-ID: <CABv=XZX3xBO6YJkZCwdgOEbVU5EW5X6afPQxE5mbQJw1NXu=+Q@mail.gmail.com>

Cool !

+1

On Wed, Apr 27, 2016 at 11:54 AM, Luke Holmquist <lholmqui at redhat.com>
wrote:

> Hello,
>
> So i've just recently published a 0.1.0 version of a node.js admin REST
> client i've been working on
>
> https://www.npmjs.com/package/keycloak-admin-client
>
> currently it only has the CRUD endpoints for Realms and Users implemented,
> but i'm following the REST API docs to get more functionality in.
>
>
> feel free to play with it
>
>
> -Luke
>
> _______________________________________________
> 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/20160427/48b4532b/attachment.html 

From thomas.darimont at googlemail.com  Wed Apr 27 18:06:37 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 28 Apr 2016 00:06:37 +0200
Subject: [keycloak-dev] Node.js REST admin client
In-Reply-To: <CABv=XZX3xBO6YJkZCwdgOEbVU5EW5X6afPQxE5mbQJw1NXu=+Q@mail.gmail.com>
References: <CALD3Fd3dqc8BFp+OKx2gP7vxr58DV2y2HrZkpOoUjLELJMM_Sw@mail.gmail.com>
	<CABv=XZX3xBO6YJkZCwdgOEbVU5EW5X6afPQxE5mbQJw1NXu=+Q@mail.gmail.com>
Message-ID: <CAK-7U1j-r1vNU=Z7p7SWLppz3oUpzrcmnvdYDbbV3EnXS-MKiw@mail.gmail.com>

Cool stuff!

2016-04-27 22:00 GMT+02:00 Helio Frota <00hf11 at gmail.com>:

> Cool !
>
> +1
>
> On Wed, Apr 27, 2016 at 11:54 AM, Luke Holmquist <lholmqui at redhat.com>
> wrote:
>
>> Hello,
>>
>> So i've just recently published a 0.1.0 version of a node.js admin REST
>> client i've been working on
>>
>> https://www.npmjs.com/package/keycloak-admin-client
>>
>> currently it only has the CRUD endpoints for Realms and Users
>> implemented, but i'm following the REST API docs to get more functionality
>> in.
>>
>>
>> feel free to play with it
>>
>>
>> -Luke
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160428/c747a8a1/attachment.html 

From sthorger at redhat.com  Thu Apr 28 01:51:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 28 Apr 2016 07:51:09 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>
	<20160425144249.GB29202@abstractj.org>
	<CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>
	<CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>
Message-ID: <CAJgngAcm0hKRVpwzhEr_DVzN+BZQ-OAWSOAYKCBaCFEmS2L8DA@mail.gmail.com>

First thing would be to create PasswordPolicySPI,
PasswordPolicyProviderFactory
and PasswordPolicyProvider. PasswordPolicyProvider should have same methods
as Policy. You'd then have to extract all built-in providers from
PasswordPolicy into PasswordPolicyProvider implementations, this should be
relatively straightforward as they are already "id" -> implementation, just
means you retrieve it with KeycloakSession rather than hard-coded in
PasswordPolicy. PasswordPolicy should then be change to use KeycloakSession
to retrieve PasswordPolicyProvider instead of hard-coded Policy
implementations.

Next step would be admin console integration. At the moment the list of
policies is hard-coded it would need to get the list of policies from
server-info instead. There are other bits that use server-info to list
providers already so take a look at that. You would probably also need to
add a method to PasswordPolicyProvider to return a description of the
policy for the admin console tooltips.

On 25 April 2016 at 18:36, Roelof Naude <roelof.naude at gmail.com> wrote:

> thank you all for the quick response.
>
> do you guys have a basic idea on how to approach the policy spi? we are
> more than willing to help out to get it done.
>
> maintaining a fork is maybe an option to resolve the immediate need, but
> would prefer to keep things upstream as much as possible.
>
> On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> We an to introduce a password policy spi soon, but for now you're stuck
>> with the built-in policies.
>> On 25 Apr 2016 16:43, "Bruno Oliveira" <bruno at abstractj.org> wrote:
>>
>>> I believe we don't have an SPI for this, yet. See:
>>> https://issues.jboss.org/browse/KEYCLOAK-2824.
>>>
>>> IMO, Argon2 is completely new and aside from the bindings, we don't have
>>> a Java implementation, yet for this. I'm not sure if is a good idea to
>>> introduce C to the codebase, but totally doable to have an SPI for
>>> policies.
>>>
>>> On 2016-04-25, Roelof Naude wrote:
>>> > hi,
>>> >
>>> > a client has requested the use of the argon2 [1, 2] password hashing
>>> > scheme. this can easily be added as an external provider. we do however
>>> > require custom password policies, e.g. memory / parallelism cost as
>>> well as
>>> > salt length. AFAIK there is no way to provide policy extensions using a
>>> > provider interface?
>>> >
>>> > would argon2 be a worthwhile contribution?
>>> >
>>> > regards
>>> > roelof.
>>> >
>>> > [1] https://github.com/P-H-C/phc-winner-argon2
>>> > [2] https://github.com/phxql/argon2-jvm
>>>
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160428/8c951ccf/attachment.html 

From roelof.naude at gmail.com  Thu Apr 28 09:37:32 2016
From: roelof.naude at gmail.com (Roelof Naude)
Date: Thu, 28 Apr 2016 15:37:32 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <CAJgngAcm0hKRVpwzhEr_DVzN+BZQ-OAWSOAYKCBaCFEmS2L8DA@mail.gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>	<20160425144249.GB29202@abstractj.org>	<CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>	<CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>
	<CAJgngAcm0hKRVpwzhEr_DVzN+BZQ-OAWSOAYKCBaCFEmS2L8DA@mail.gmail.com>
Message-ID: <5722121C.3030107@gmail.com>

thank you. have made some headway with this.

there is a slight issue though. Providers are cached and thus mostly 
stateless.

password policies on the other hand are constructed on-demand and may 
contain configuration. this configuration can be different between 
various realms, e.g. HashIterations could be 20 for realm1 and 200 for 
realm2.

the current provider loading mechanisms caches both the factory and 
provider instances.

1. is there a session instance per realm? if so, then there is no issue
2. if not, how do you propose creating policy instances per realm?

PasswordPolicyFactory could expose an extra method, create(String arg), 
but the provider loading mechanism will ignore it. one could add 
specific knowledge of that method, but that feels wrong.

another option would be to teach KeycloakSession to return a 
ProviderFactory instance. PasswordPolicy could call this method to 
create PasswordPolicyProvider instances on-demand. this method would 
delegate to the underlying KeycloakSessonFactory to lookup the 
appropriate factory.

this last option could work. would prefer to clear it with you guys 
first though.

On 04/28/2016 07:51 AM, Stian Thorgersen wrote:
> First thing would be to create PasswordPolicySPI,
> PasswordPolicyProviderFactory
> and PasswordPolicyProvider. PasswordPolicyProvider should have same
> methods as Policy. You'd then have to extract all built-in providers
> from PasswordPolicy into PasswordPolicyProvider implementations, this
> should be relatively straightforward as they are already "id" ->
> implementation, just means you retrieve it with KeycloakSession rather
> than hard-coded in PasswordPolicy. PasswordPolicy should then be change
> to use KeycloakSession to retrieve PasswordPolicyProvider instead of
> hard-coded Policy implementations.
>
> Next step would be admin console integration. At the moment the list of
> policies is hard-coded it would need to get the list of policies from
> server-info instead. There are other bits that use server-info to list
> providers already so take a look at that. You would probably also need
> to add a method to PasswordPolicyProvider to return a description of the
> policy for the admin console tooltips.
>
> On 25 April 2016 at 18:36, Roelof Naude <roelof.naude at gmail.com
> <mailto:roelof.naude at gmail.com>> wrote:
>
>     thank you all for the quick response.
>
>     do you guys have a basic idea on how to approach the policy spi? we
>     are more than willing to help out to get it done.
>
>     maintaining a fork is maybe an option to resolve the immediate need,
>     but would prefer to keep things upstream as much as possible.
>
>     On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>         We an to introduce a password policy spi soon, but for now
>         you're stuck with the built-in policies.
>
>         On 25 Apr 2016 16:43, "Bruno Oliveira" <bruno at abstractj.org
>         <mailto:bruno at abstractj.org>> wrote:
>
>             I believe we don't have an SPI for this, yet. See:
>             https://issues.jboss.org/browse/KEYCLOAK-2824.
>
>             IMO, Argon2 is completely new and aside from the bindings,
>             we don't have
>             a Java implementation, yet for this. I'm not sure if is a
>             good idea to
>             introduce C to the codebase, but totally doable to have an
>             SPI for
>             policies.
>
>             On 2016-04-25, Roelof Naude wrote:
>              > hi,
>              >
>              > a client has requested the use of the argon2 [1, 2]
>             password hashing
>              > scheme. this can easily be added as an external provider.
>             we do however
>              > require custom password policies, e.g. memory /
>             parallelism cost as well as
>              > salt length. AFAIK there is no way to provide policy
>             extensions using a
>              > provider interface?
>              >
>              > would argon2 be a worthwhile contribution?
>              >
>              > regards
>              > roelof.
>              >
>              > [1] https://github.com/P-H-C/phc-winner-argon2
>              > [2] https://github.com/phxql/argon2-jvm
>
>              > _______________________________________________
>              > 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
>
>
>             --
>
>             abstractj
>             PGP: 0x84DC9914
>             _______________________________________________
>             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
>
>
>

From bburke at redhat.com  Thu Apr 28 11:50:09 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Apr 2016 11:50:09 -0400
Subject: [keycloak-dev] something we should have done :(
Message-ID: <0ef8fc6a-0da7-a116-9bba-a4f0b2df2236@redhat.com>

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



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160428/7779e939/attachment.html 

From sthorger at redhat.com  Thu Apr 28 11:53:40 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 28 Apr 2016 17:53:40 +0200
Subject: [keycloak-dev] something we should have done :(
In-Reply-To: <0ef8fc6a-0da7-a116-9bba-a4f0b2df2236@redhat.com>
References: <0ef8fc6a-0da7-a116-9bba-a4f0b2df2236@redhat.com>
Message-ID: <CAJgngAf3Wk725=C54DC0h=i+iQ_N60nuv+5JU_K4b7XJisnEXQ@mail.gmail.com>

+100

On 28 April 2016 at 17:50, Bill Burke <bburke at redhat.com> wrote:

> https://issues.jboss.org/browse/KEYCLOAK-2944
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160428/51d35888/attachment.html 

From sthorger at redhat.com  Thu Apr 28 12:35:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 28 Apr 2016 18:35:13 +0200
Subject: [keycloak-dev] Keycloak 1.9.3.Final Released
Message-ID: <CAJgngAda4mwj2M+Sa7kLWGTnduDQQcQ95VeCwsG0pv7E7Yiq2Q@mail.gmail.com>

We've just release 1.9.3.Final. This release has a few bug fixes, but
mainly we've focused on increasing test coverage for this release.

For the full list of resolved issues check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.3.Final>
and
to download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160428/eb3fe804/attachment.html 

From bburke at redhat.com  Thu Apr 28 17:44:47 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Apr 2016 17:44:47 -0400
Subject: [keycloak-dev] max entry default for realm cache?
Message-ID: <25121b84-9f8c-8603-8d3d-ce54beb159ee@redhat.com>

What is the max entry default for realm cache? Is it unbounded? I'm 
looking at infinispan docs and it seems the default eviction strategy is 
nothing.


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

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

From fabricio.milone at shinetech.com  Thu Apr 28 21:43:28 2016
From: fabricio.milone at shinetech.com (Fabricio Milone)
Date: Fri, 29 Apr 2016 11:43:28 +1000
Subject: [keycloak-dev] max entry default for realm cache?
In-Reply-To: <25121b84-9f8c-8603-8d3d-ce54beb159ee@redhat.com>
References: <25121b84-9f8c-8603-8d3d-ce54beb159ee@redhat.com>
Message-ID: <CAOjtoUOWfFbnDgEvxMAP-pMdLrp+2RV1t4yG1CqZWUBe+xda_Q@mail.gmail.com>

As per the documentation on
http://infinispan.org/docs/8.0.x/user_guide/user_guide.html#_more_defaults
and keycloak standalone.xml file, I can see that none of those caches have
eviction enabled.

I'm just wondering why is the realm cache the one you are asking for.
Wouldn't be more dangerous in terms of memory the sessions or users cache
instead?


On 29 April 2016 at 07:44, Bill Burke <bburke at redhat.com> wrote:

> What is the max entry default for realm cache? Is it unbounded?  I'm
> looking at infinispan docs and it seems the default eviction strategy is
> nothing.
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
*Fabricio Milone*
Developer

*Shine Consulting *

30/600 Bourke Street

Melbourne VIC 3000

T: 03 8488 9939

M: 04 3200 4006


www.shinetech.com  *a* passion for excellence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/be4f16f2/attachment.html 

From sthorger at redhat.com  Fri Apr 29 00:02:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 06:02:24 +0200
Subject: [keycloak-dev] Thinking about step-up authentication and token
	timeouts
Message-ID: <CAJgngAf5VX-+StUGCaZYH2asMori7X2g5zFVcn8SrOT=XjRCKg@mail.gmail.com>

Clients should be able to obtain tokens with reduced scope and longer or
shorter expiration, then later request new tokens with increased scope and
different expiration. They should also be able to require different levels
of authentication and also require re-authentication.

An application may for example:

* At first only need users email - this would allow showing the name +
email. In this situation a long expiration access token in combination with
implicit flow would do. It's also not necessary to re-authenticate the user
and a user that has been logged-in for months or even a year is fine.

* When a user clicks on orders it would require the password and extend
scope to be able to view orders. Now you'll want to switch to short
expiration access tokens and authorization code grant. You'll also want to
make sure the user logged-in fairly recently, max 30 days could be sensible.

* When a user tries to purchase something the user now has to provide the
OTP to be able to purchase with saved credit card details. You'll also want
to make sure the user logged-in very recently, max a day could be required.
There may also be cases where you always want the user to re-authenticate,
for example when trying to purchase something over a certain price level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/d39fd3c7/attachment.html 

From sthorger at redhat.com  Fri Apr 29 00:03:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 06:03:13 +0200
Subject: [keycloak-dev] max entry default for realm cache?
In-Reply-To: <25121b84-9f8c-8603-8d3d-ce54beb159ee@redhat.com>
References: <25121b84-9f8c-8603-8d3d-ce54beb159ee@redhat.com>
Message-ID: <CAJgngAfjxUzCyRA8MNEk-A6n9=6BH=2wM=f2xjNS952wikv2fA@mail.gmail.com>

It's unbounded, but is that a problem?

On 28 April 2016 at 23:44, Bill Burke <bburke at redhat.com> wrote:

> What is the max entry default for realm cache? Is it unbounded?  I'm
> looking at infinispan docs and it seems the default eviction strategy is
> nothing.
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160429/d9eeb8db/attachment-0001.html 

From sthorger at redhat.com  Fri Apr 29 01:58:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 07:58:24 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <5722121C.3030107@gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>
	<20160425144249.GB29202@abstractj.org>
	<CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>
	<CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>
	<CAJgngAcm0hKRVpwzhEr_DVzN+BZQ-OAWSOAYKCBaCFEmS2L8DA@mail.gmail.com>
	<5722121C.3030107@gmail.com>
Message-ID: <CAJgngAeasPJWDsp1rUsSMReZE=tcQm_X_rJJc6bNgKUsGYY47g@mail.gmail.com>

Simplest option is to simply add the config to the verify method.

We have some other SPIs that have more than one instance of a given
provider per-realm, but as you say they're not associated with the session.
This could cause them not to be closed, or to have multiple instances with
same config created per-session.

On 28 April 2016 at 15:37, Roelof Naude <roelof.naude at gmail.com> wrote:

> thank you. have made some headway with this.
>
> there is a slight issue though. Providers are cached and thus mostly
> stateless.
>
> password policies on the other hand are constructed on-demand and may
> contain configuration. this configuration can be different between various
> realms, e.g. HashIterations could be 20 for realm1 and 200 for realm2.
>
> the current provider loading mechanisms caches both the factory and
> provider instances.
>
> 1. is there a session instance per realm? if so, then there is no issue
> 2. if not, how do you propose creating policy instances per realm?
>
> PasswordPolicyFactory could expose an extra method, create(String arg),
> but the provider loading mechanism will ignore it. one could add specific
> knowledge of that method, but that feels wrong.
>
> another option would be to teach KeycloakSession to return a
> ProviderFactory instance. PasswordPolicy could call this method to create
> PasswordPolicyProvider instances on-demand. this method would delegate to
> the underlying KeycloakSessonFactory to lookup the appropriate factory.
>
> this last option could work. would prefer to clear it with you guys first
> though.
>
> On 04/28/2016 07:51 AM, Stian Thorgersen wrote:
>
>> First thing would be to create PasswordPolicySPI,
>> PasswordPolicyProviderFactory
>> and PasswordPolicyProvider. PasswordPolicyProvider should have same
>> methods as Policy. You'd then have to extract all built-in providers
>> from PasswordPolicy into PasswordPolicyProvider implementations, this
>> should be relatively straightforward as they are already "id" ->
>> implementation, just means you retrieve it with KeycloakSession rather
>> than hard-coded in PasswordPolicy. PasswordPolicy should then be change
>> to use KeycloakSession to retrieve PasswordPolicyProvider instead of
>> hard-coded Policy implementations.
>>
>> Next step would be admin console integration. At the moment the list of
>> policies is hard-coded it would need to get the list of policies from
>> server-info instead. There are other bits that use server-info to list
>> providers already so take a look at that. You would probably also need
>> to add a method to PasswordPolicyProvider to return a description of the
>> policy for the admin console tooltips.
>>
>> On 25 April 2016 at 18:36, Roelof Naude <roelof.naude at gmail.com
>> <mailto:roelof.naude at gmail.com>> wrote:
>>
>>     thank you all for the quick response.
>>
>>     do you guys have a basic idea on how to approach the policy spi? we
>>     are more than willing to help out to get it done.
>>
>>     maintaining a fork is maybe an option to resolve the immediate need,
>>     but would prefer to keep things upstream as much as possible.
>>
>>     On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen
>>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>         We an to introduce a password policy spi soon, but for now
>>         you're stuck with the built-in policies.
>>
>>         On 25 Apr 2016 16:43, "Bruno Oliveira" <bruno at abstractj.org
>>         <mailto:bruno at abstractj.org>> wrote:
>>
>>             I believe we don't have an SPI for this, yet. See:
>>             https://issues.jboss.org/browse/KEYCLOAK-2824.
>>
>>             IMO, Argon2 is completely new and aside from the bindings,
>>             we don't have
>>             a Java implementation, yet for this. I'm not sure if is a
>>             good idea to
>>             introduce C to the codebase, but totally doable to have an
>>             SPI for
>>             policies.
>>
>>             On 2016-04-25, Roelof Naude wrote:
>>              > hi,
>>              >
>>              > a client has requested the use of the argon2 [1, 2]
>>             password hashing
>>              > scheme. this can easily be added as an external provider.
>>             we do however
>>              > require custom password policies, e.g. memory /
>>             parallelism cost as well as
>>              > salt length. AFAIK there is no way to provide policy
>>             extensions using a
>>              > provider interface?
>>              >
>>              > would argon2 be a worthwhile contribution?
>>              >
>>              > regards
>>              > roelof.
>>              >
>>              > [1] https://github.com/P-H-C/phc-winner-argon2
>>              > [2] https://github.com/phxql/argon2-jvm
>>
>>              > _______________________________________________
>>              > 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
>>
>>
>>             --
>>
>>             abstractj
>>             PGP: 0x84DC9914
>>             _______________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/844f8a32/attachment.html 

From sthorger at redhat.com  Fri Apr 29 02:00:44 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 08:00:44 +0200
Subject: [keycloak-dev] User Federation provider instances
Message-ID: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>

Looking at the code for user federation it looks like user federation
provider instances with the same configuration can be created multiple
times for a single session. Also they are never closed to resources aren't
released.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/612878df/attachment.html 

From mposolda at redhat.com  Fri Apr 29 03:43:54 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 29 Apr 2016 09:43:54 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
Message-ID: <572310BA.4060904@redhat.com>

Yes, AFAIK we have open JIRA for this for a long time ago.

It's the same issue for IdentityProvider (and maybe some others SPI too) 
that they bypass "official" way for create provider via 
session.getProvider(providerClazz) and hence they are not registered in 
KeycloakSession and "close" method is not called for them.

The issue is that our SPI is a bit limited IMO and doesn't support 
"stateful" providers. The providers are created through 
"ProviderFactory.create(KeycloakSession)". So the only available state 
of provider ATM is just ProviderFactory + KeycloakSession, which is 
sometimes not sufficient.


I can see 2 possibilities to address:

1) Always make the provider implementation "stateless" and ensure all 
the state is passed as argument to provider methods. This is what we 
already do for some providers (for example all methods of UserProvider 
has RealmModel as parameter). So if we rewrite UserFederation SPI that 
UserFederationProviderModel will be passed as argument to all methods of 
UserFederationProvider, then it can use "official" way too.


2) Improve the SPI, so it can properly support "stateful" providers. 
This is more flexible then (1) and I would go this way long term.

I am thinking about something like this:

public interface StatefulProvider<S> extends Provider {
}


public class StatefulProviderFactory<T extends StatefulProvider, S> {

T create(KeycloakSession session, S state);

      .......
}


and on KEycloakSession new method like this:

<S,T extends StatefulProvider<S>>T getProvider(Class<T> providerClazz, String id,S state);


The "state" will need to properly implement equals and hashCode, so the 
SPI can deal with it and not create another instance of StatefulProvider 
if it was called for this KeycloakSession with same state before.

Marek


On 29/04/16 08:00, Stian Thorgersen wrote:
> Looking at the code for user federation it looks like user federation 
> provider instances with the same configuration can be created multiple 
> times for a single session. Also they are never closed to resources 
> aren't released.
>
>
> _______________________________________________
> 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/20160429/3446c8b6/attachment.html 

From roelof.naude at gmail.com  Fri Apr 29 03:48:05 2016
From: roelof.naude at gmail.com (Roelof Naude)
Date: Fri, 29 Apr 2016 09:48:05 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <CAJgngAeasPJWDsp1rUsSMReZE=tcQm_X_rJJc6bNgKUsGYY47g@mail.gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>	<20160425144249.GB29202@abstractj.org>	<CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>	<CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>	<CAJgngAcm0hKRVpwzhEr_DVzN+BZQ-OAWSOAYKCBaCFEmS2L8DA@mail.gmail.com>	<5722121C.3030107@gmail.com>
	<CAJgngAeasPJWDsp1rUsSMReZE=tcQm_X_rJJc6bNgKUsGYY47g@mail.gmail.com>
Message-ID: <572311B5.30504@gmail.com>

hi,

adding the config to the verify / validate method makes no sense. take 
for instance HashIterations. it needs to keep the config for later when 
the password encode takes place. PasswordPolicy::validate is called 
after construction of the policies...at a time when the configuration 
has been parsed already. re-parsing the config for every validate can be 
expensive.

PasswordPolicyProvider implementations will most likely not access 
external resources. granted, one cannot foresee all future usage 
patterns either.

On 04/29/2016 07:58 AM, Stian Thorgersen wrote:
> Simplest option is to simply add the config to the verify method.
>
> We have some other SPIs that have more than one instance of a given
> provider per-realm, but as you say they're not associated with the
> session. This could cause them not to be closed, or to have multiple
> instances with same config created per-session.
>
> On 28 April 2016 at 15:37, Roelof Naude <roelof.naude at gmail.com
> <mailto:roelof.naude at gmail.com>> wrote:
>
>     thank you. have made some headway with this.
>
>     there is a slight issue though. Providers are cached and thus mostly
>     stateless.
>
>     password policies on the other hand are constructed on-demand and
>     may contain configuration. this configuration can be different
>     between various realms, e.g. HashIterations could be 20 for realm1
>     and 200 for realm2.
>
>     the current provider loading mechanisms caches both the factory and
>     provider instances.
>
>     1. is there a session instance per realm? if so, then there is no issue
>     2. if not, how do you propose creating policy instances per realm?
>
>     PasswordPolicyFactory could expose an extra method, create(String
>     arg), but the provider loading mechanism will ignore it. one could
>     add specific knowledge of that method, but that feels wrong.
>
>     another option would be to teach KeycloakSession to return a
>     ProviderFactory instance. PasswordPolicy could call this method to
>     create PasswordPolicyProvider instances on-demand. this method would
>     delegate to the underlying KeycloakSessonFactory to lookup the
>     appropriate factory.
>
>     this last option could work. would prefer to clear it with you guys
>     first though.
>
>     On 04/28/2016 07:51 AM, Stian Thorgersen wrote:
>
>         First thing would be to create PasswordPolicySPI,
>         PasswordPolicyProviderFactory
>         and PasswordPolicyProvider. PasswordPolicyProvider should have same
>         methods as Policy. You'd then have to extract all built-in providers
>         from PasswordPolicy into PasswordPolicyProvider implementations,
>         this
>         should be relatively straightforward as they are already "id" ->
>         implementation, just means you retrieve it with KeycloakSession
>         rather
>         than hard-coded in PasswordPolicy. PasswordPolicy should then be
>         change
>         to use KeycloakSession to retrieve PasswordPolicyProvider instead of
>         hard-coded Policy implementations.
>
>         Next step would be admin console integration. At the moment the
>         list of
>         policies is hard-coded it would need to get the list of policies
>         from
>         server-info instead. There are other bits that use server-info
>         to list
>         providers already so take a look at that. You would probably
>         also need
>         to add a method to PasswordPolicyProvider to return a
>         description of the
>         policy for the admin console tooltips.
>
>         On 25 April 2016 at 18:36, Roelof Naude <roelof.naude at gmail.com
>         <mailto:roelof.naude at gmail.com>
>         <mailto:roelof.naude at gmail.com <mailto:roelof.naude at gmail.com>>>
>         wrote:
>
>              thank you all for the quick response.
>
>              do you guys have a basic idea on how to approach the policy
>         spi? we
>              are more than willing to help out to get it done.
>
>              maintaining a fork is maybe an option to resolve the
>         immediate need,
>              but would prefer to keep things upstream as much as possible.
>
>              On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen
>              <sthorger at redhat.com <mailto:sthorger at redhat.com>
>         <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>> wrote:
>
>                  We an to introduce a password policy spi soon, but for now
>                  you're stuck with the built-in policies.
>
>                  On 25 Apr 2016 16:43, "Bruno Oliveira"
>         <bruno at abstractj.org <mailto:bruno at abstractj.org>
>                  <mailto:bruno at abstractj.org
>         <mailto:bruno at abstractj.org>>> wrote:
>
>                      I believe we don't have an SPI for this, yet. See:
>         https://issues.jboss.org/browse/KEYCLOAK-2824.
>
>                      IMO, Argon2 is completely new and aside from the
>         bindings,
>                      we don't have
>                      a Java implementation, yet for this. I'm not sure
>         if is a
>                      good idea to
>                      introduce C to the codebase, but totally doable to
>         have an
>                      SPI for
>                      policies.
>
>                      On 2016-04-25, Roelof Naude wrote:
>                       > hi,
>                       >
>                       > a client has requested the use of the argon2 [1, 2]
>                      password hashing
>                       > scheme. this can easily be added as an external
>         provider.
>                      we do however
>                       > require custom password policies, e.g. memory /
>                      parallelism cost as well as
>                       > salt length. AFAIK there is no way to provide policy
>                      extensions using a
>                       > provider interface?
>                       >
>                       > would argon2 be a worthwhile contribution?
>                       >
>                       > regards
>                       > roelof.
>                       >
>                       > [1] https://github.com/P-H-C/phc-winner-argon2
>                       > [2] https://github.com/phxql/argon2-jvm
>
>                       > _______________________________________________
>                       > keycloak-dev mailing list
>                       > keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>                      <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>>
>                       >
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>                      --
>
>                      abstractj
>                      PGP: 0x84DC9914
>                      _______________________________________________
>                      keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>                      <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>

From mposolda at redhat.com  Fri Apr 29 04:01:42 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 29 Apr 2016 10:01:42 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <572310BA.4060904@redhat.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
Message-ID: <572314E6.7070009@redhat.com>

On 29/04/16 09:43, Marek Posolda wrote:
> Yes, AFAIK we have open JIRA for this for a long time ago.
>
> It's the same issue for IdentityProvider (and maybe some others SPI 
> too) that they bypass "official" way for create provider via 
> session.getProvider(providerClazz) and hence they are not registered 
> in KeycloakSession and "close" method is not called for them.
>
> The issue is that our SPI is a bit limited IMO and doesn't support 
> "stateful" providers. The providers are created through 
> "ProviderFactory.create(KeycloakSession)". So the only available state 
> of provider ATM is just ProviderFactory + KeycloakSession, which is 
> sometimes not sufficient.
>
>
> I can see 2 possibilities to address:
>
> 1) Always make the provider implementation "stateless" and ensure all 
> the state is passed as argument to provider methods. This is what we 
> already do for some providers (for example all methods of UserProvider 
> has RealmModel as parameter). So if we rewrite UserFederation SPI that 
> UserFederationProviderModel will be passed as argument to all methods 
> of UserFederationProvider, then it can use "official" way too.
>
>
> 2) Improve the SPI, so it can properly support "stateful" providers. 
> This is more flexible then (1) and I would go this way long term.
>
> I am thinking about something like this:
>
> public interface StatefulProvider<S> extends Provider {
> }
>
>
> public class StatefulProviderFactory<T extends StatefulProvider, S> {
>
> T create(KeycloakSession session, S state);
>
>      .......
> }
>
>
> and on KEycloakSession new method like this:
>
> <S,T extends StatefulProvider<S>>T getProvider(Class<T> providerClazz, String id,S state);
>
> The "state" will need to properly implement equals and hashCode, so 
> the SPI can deal with it and not create another instance of 
> StatefulProvider if it was called for this KeycloakSession with same 
> state before.
Just adding the example how easily it will work for UserFederation . The 
state will be UserFederationProviderModel, so it will be like:

UserFederationProviderModel providerModel1 = .... // get somehow from DB
UserFederationProviderModel providerModel2 = .... // get somehow from DB

UserFederationProvider ldap1 = 
session.getProvider(UserFederationProvider.class, "ldap", providerModel1);
UserFederationProvider ldap2 = 
session.getProvider(UserFederationProvider.class, "ldap", 
providerModel2); // Will return different instance then "ldap1" as it's 
different state (providerModel) used
UserFederationProvider ldap3 = 
session.getProvider(UserFederationProvider.class, "ldap", 
providerModel1); // Will return existing "ldap1" as it was already used 
in this KeycloakSession with this state

At the end of session are 2 registered LDAP providers properly closed.

Marek
>
> Marek
>
>
> On 29/04/16 08:00, Stian Thorgersen wrote:
>> Looking at the code for user federation it looks like user federation 
>> provider instances with the same configuration can be created 
>> multiple times for a single session. Also they are never closed to 
>> resources aren't released.
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/939b3800/attachment.html 

From sthorger at redhat.com  Fri Apr 29 04:22:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 10:22:09 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
	<CAJgngAfz=fzRFTrTrmxq0q9S6OsxiQZ0NgqBsOi4Na45eVNcdg@mail.gmail.com>
	<CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
Message-ID: <CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>

We have 3 types of providers:

* Server configured - no config or config from keycloak-server
* Realm configured - config from realm model
* Instance configured - multiple instances per realm

Removing master realm as we plan to do means that realm configured provider
factories can get realm from KeycloakContext as there's only one realm
per-session.

For instance configured I propose we add getProvider(Class c, String id,
String instanceId) to provider factory. The it's up to the provider factory
itself to extract  the config from the realm model or another source. It
also means that the session can easily keep track of these and only create
one id+instanceId per session.
On 29 Apr 2016 09:43, "Marek Posolda" <mposolda at redhat.com> wrote:

Yes, AFAIK we have open JIRA for this for a long time ago.

It's the same issue for IdentityProvider (and maybe some others SPI too)
that they bypass "official" way for create provider via
session.getProvider(providerClazz) and hence they are not registered in
KeycloakSession and "close" method is not called for them.

The issue is that our SPI is a bit limited IMO and doesn't support
"stateful" providers. The providers are created through
"ProviderFactory.create(KeycloakSession)". So the only available state of
provider ATM is just ProviderFactory + KeycloakSession, which is sometimes
not sufficient.


I can see 2 possibilities to address:

1) Always make the provider implementation "stateless" and ensure all the
state is passed as argument to provider methods. This is what we already do
for some providers (for example all methods of UserProvider has RealmModel
as parameter). So if we rewrite UserFederation SPI that
UserFederationProviderModel will be passed as argument to all methods of
UserFederationProvider, then it can use "official" way too.


2) Improve the SPI, so it can properly support "stateful" providers. This
is more flexible then (1) and I would go this way long term.

I am thinking about something like this:

public interface StatefulProvider<S> extends Provider {
}


public class StatefulProviderFactory<T extends StatefulProvider, S> {

     T create(KeycloakSession session, S state);

     .......
}


and on KEycloakSession new method like this:

<S, T extends StatefulProvider<S>> T getProvider(Class<T>
providerClazz, String id, S state);


The "state" will need to properly implement equals and hashCode, so the SPI
can deal with it and not create another instance of StatefulProvider if it
was called for this KeycloakSession with same state before.

Marek



On 29/04/16 08:00, Stian Thorgersen wrote:

Looking at the code for user federation it looks like user federation
provider instances with the same configuration can be created multiple
times for a single session. Also they are never closed to resources aren't
released.


_______________________________________________
keycloak-dev mailing
listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/61311577/attachment.html 

From mposolda at redhat.com  Fri Apr 29 04:58:44 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 29 Apr 2016 10:58:44 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
	<CAJgngAfz=fzRFTrTrmxq0q9S6OsxiQZ0NgqBsOi4Na45eVNcdg@mail.gmail.com>
	<CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
	<CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>
Message-ID: <57232244.90205@redhat.com>

On 29/04/16 10:22, Stian Thorgersen wrote:
>
> We have 3 types of providers:
>
> * Server configured - no config or config from keycloak-server
> * Realm configured - config from realm model
> * Instance configured - multiple instances per realm
>
> Removing master realm as we plan to do means that realm configured 
> provider factories can get realm from KeycloakContext as there's only 
> one realm per-session.
>
In theory yes. In practice there might be still corner cases when you 
need to deal with multiple realms inside same KeycloakSession (like 
export/import for example). But hope we can handle most of the cases by 
assume that KeycloakContext has correct realm set.
>
> For instance configured I propose we add getProvider(Class c, String 
> id, String instanceId) to provider factory. The it's up to the 
> provider factory itself to extract the config from the realm model or 
> another source. It also means that the session can easily keep track 
> of these and only create one id+instanceId per session.
>
ah, ok. I somehow missed the proposal.

It should work fine, I think it's quite similar to what I proposed. 
Despite I proposed to send whole state to provider factory (aka. 
UserFederationProviderModel) instead of just instanceId and then assume 
that state must properly implement "hashCode" to ensure that session can 
keep track of these and return provider of already used state.

Marek
> On 29 Apr 2016 09:43, "Marek Posolda" <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Yes, AFAIK we have open JIRA for this for a long time ago.
>
>     It's the same issue for IdentityProvider (and maybe some others
>     SPI too) that they bypass "official" way for create provider via
>     session.getProvider(providerClazz) and hence they are not
>     registered in KeycloakSession and "close" method is not called for
>     them.
>
>     The issue is that our SPI is a bit limited IMO and doesn't support
>     "stateful" providers. The providers are created through
>     "ProviderFactory.create(KeycloakSession)". So the only available
>     state of provider ATM is just ProviderFactory + KeycloakSession,
>     which is sometimes not sufficient.
>
>
>     I can see 2 possibilities to address:
>
>     1) Always make the provider implementation "stateless" and ensure
>     all the state is passed as argument to provider methods. This is
>     what we already do for some providers (for example all methods of
>     UserProvider has RealmModel as parameter). So if we rewrite
>     UserFederation SPI that UserFederationProviderModel will be passed
>     as argument to all methods of UserFederationProvider, then it can
>     use "official" way too.
>
>
>     2) Improve the SPI, so it can properly support "stateful"
>     providers. This is more flexible then (1) and I would go this way
>     long term.
>
>     I am thinking about something like this:
>
>     public interface StatefulProvider<S> extends Provider {
>     }
>
>
>     public class StatefulProviderFactory<T extends StatefulProvider, S> {
>
>     T create(KeycloakSession session, S state);
>
>          .......
>     }
>
>
>     and on KEycloakSession new method like this:
>
>     <S,T extends StatefulProvider<S>>T getProvider(Class<T> providerClazz, String id,S state);
>
>
>     The "state" will need to properly implement equals and hashCode,
>     so the SPI can deal with it and not create another instance of
>     StatefulProvider if it was called for this KeycloakSession with
>     same state before.
>
>     Marek
>
>
>
>     On 29/04/16 08:00, Stian Thorgersen wrote:
>>     Looking at the code for user federation it looks like user
>>     federation provider instances with the same configuration can be
>>     created multiple times for a single session. Also they are never
>>     closed to resources aren't released.
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From sthorger at redhat.com  Fri Apr 29 05:06:17 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 11:06:17 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <57232244.90205@redhat.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
	<CAJgngAfz=fzRFTrTrmxq0q9S6OsxiQZ0NgqBsOi4Na45eVNcdg@mail.gmail.com>
	<CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
	<CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>
	<57232244.90205@redhat.com>
Message-ID: <CAJgngAdbwU6ub264YHe6t2w5hidtS5h=vxH6b4OdQ8Mhmaa+0Q@mail.gmail.com>

On 29 April 2016 at 10:58, Marek Posolda <mposolda at redhat.com> wrote:

> On 29/04/16 10:22, Stian Thorgersen wrote:
>
> We have 3 types of providers:
>
> * Server configured - no config or config from keycloak-server
> * Realm configured - config from realm model
> * Instance configured - multiple instances per realm
>
> Removing master realm as we plan to do means that realm configured
> provider factories can get realm from KeycloakContext as there's only one
> realm per-session.
>
> In theory yes. In practice there might be still corner cases when you need
> to deal with multiple realms inside same KeycloakSession (like
> export/import for example). But hope we can handle most of the cases by
> assume that KeycloakContext has correct realm set.
>

Corner cases like that is easy - we'd use create a KeycloakSession
per-realm, making sure KeycloakContext is initialized properly.


>
> For instance configured I propose we add getProvider(Class c, String id,
> String instanceId) to provider factory. The it's up to the provider factory
> itself to extract  the config from the realm model or another source. It
> also means that the session can easily keep track of these and only create
> one id+instanceId per session.
>
> ah, ok. I somehow missed the proposal.
>
> It should work fine, I think it's quite similar to what I proposed.
> Despite I proposed to send whole state to provider factory (aka.
> UserFederationProviderModel) instead of just instanceId and then assume
> that state must properly implement "hashCode" to ensure that session can
> keep track of these and return provider of already used state.
>

Yup, very similar, but I think the devil is in the details. In my proposal
the factory itself knows how to extract the state, so it's then up to the
factory to decide how state should be stored. A custom provider may need to
store config in a separate custom entity, which KeycloakSessionFactory
wouldn't know how to retrieve.


>
>
> Marek
>
> On 29 Apr 2016 09:43, "Marek Posolda" <mposolda at redhat.com> wrote:
>
> Yes, AFAIK we have open JIRA for this for a long time ago.
>
> It's the same issue for IdentityProvider (and maybe some others SPI too)
> that they bypass "official" way for create provider via
> session.getProvider(providerClazz) and hence they are not registered in
> KeycloakSession and "close" method is not called for them.
>
> The issue is that our SPI is a bit limited IMO and doesn't support
> "stateful" providers. The providers are created through
> "ProviderFactory.create(KeycloakSession)". So the only available state of
> provider ATM is just ProviderFactory + KeycloakSession, which is sometimes
> not sufficient.
>
>
> I can see 2 possibilities to address:
>
> 1) Always make the provider implementation "stateless" and ensure all the
> state is passed as argument to provider methods. This is what we already do
> for some providers (for example all methods of UserProvider has RealmModel
> as parameter). So if we rewrite UserFederation SPI that
> UserFederationProviderModel will be passed as argument to all methods of
> UserFederationProvider, then it can use "official" way too.
>
>
> 2) Improve the SPI, so it can properly support "stateful" providers. This
> is more flexible then (1) and I would go this way long term.
>
> I am thinking about something like this:
>
> public interface StatefulProvider<S> extends Provider {
> }
>
>
> public class StatefulProviderFactory<T extends StatefulProvider, S> {
>
>      T create(KeycloakSession session, S state);
>
>      .......
> }
>
>
> and on KEycloakSession new method like this:
>
> <S, T extends StatefulProvider<S>> T getProvider(Class<T> providerClazz, String id, S state);
>
>
> The "state" will need to properly implement equals and hashCode, so the
> SPI can deal with it and not create another instance of StatefulProvider if
> it was called for this KeycloakSession with same state before.
>
> Marek
>
>
>
> On 29/04/16 08:00, Stian Thorgersen wrote:
>
> Looking at the code for user federation it looks like user federation
> provider instances with the same configuration can be created multiple
> times for a single session. Also they are never closed to resources aren't
> released.
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/a6255713/attachment.html 

From sthorger at redhat.com  Fri Apr 29 05:10:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 11:10:43 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <572311B5.30504@gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>
	<20160425144249.GB29202@abstractj.org>
	<CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>
	<CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>
	<CAJgngAcm0hKRVpwzhEr_DVzN+BZQ-OAWSOAYKCBaCFEmS2L8DA@mail.gmail.com>
	<5722121C.3030107@gmail.com>
	<CAJgngAeasPJWDsp1rUsSMReZE=tcQm_X_rJJc6bNgKUsGYY47g@mail.gmail.com>
	<572311B5.30504@gmail.com>
Message-ID: <CAJgngAdmn39t3eG7jjkQCXJ6FBwUq6PP=rLUvfMqNF9gJG99xw@mail.gmail.com>

Pass in PasswordPolicy then. PasswordPolicy can store the config in the
correct format. getInt(String provider) would parse string and store as an
int in a map.

This can be improved later, we're currently having a separate discussion
about adding something like this. Ideally password policies would also
support more advanced configuration like authenticators, mappers, etc
already do. That on the other side is more work. If you want to do
something like what they do that would be great though.

On 29 April 2016 at 09:48, Roelof Naude <roelof.naude at gmail.com> wrote:

> hi,
>
> adding the config to the verify / validate method makes no sense. take for
> instance HashIterations. it needs to keep the config for later when the
> password encode takes place. PasswordPolicy::validate is called after
> construction of the policies...at a time when the configuration has been
> parsed already. re-parsing the config for every validate can be expensive.
>
> PasswordPolicyProvider implementations will most likely not access
> external resources. granted, one cannot foresee all future usage patterns
> either.
>
> On 04/29/2016 07:58 AM, Stian Thorgersen wrote:
>
>> Simplest option is to simply add the config to the verify method.
>>
>> We have some other SPIs that have more than one instance of a given
>> provider per-realm, but as you say they're not associated with the
>> session. This could cause them not to be closed, or to have multiple
>> instances with same config created per-session.
>>
>> On 28 April 2016 at 15:37, Roelof Naude <roelof.naude at gmail.com
>> <mailto:roelof.naude at gmail.com>> wrote:
>>
>>     thank you. have made some headway with this.
>>
>>     there is a slight issue though. Providers are cached and thus mostly
>>     stateless.
>>
>>     password policies on the other hand are constructed on-demand and
>>     may contain configuration. this configuration can be different
>>     between various realms, e.g. HashIterations could be 20 for realm1
>>     and 200 for realm2.
>>
>>     the current provider loading mechanisms caches both the factory and
>>     provider instances.
>>
>>     1. is there a session instance per realm? if so, then there is no
>> issue
>>     2. if not, how do you propose creating policy instances per realm?
>>
>>     PasswordPolicyFactory could expose an extra method, create(String
>>     arg), but the provider loading mechanism will ignore it. one could
>>     add specific knowledge of that method, but that feels wrong.
>>
>>     another option would be to teach KeycloakSession to return a
>>     ProviderFactory instance. PasswordPolicy could call this method to
>>     create PasswordPolicyProvider instances on-demand. this method would
>>     delegate to the underlying KeycloakSessonFactory to lookup the
>>     appropriate factory.
>>
>>     this last option could work. would prefer to clear it with you guys
>>     first though.
>>
>>     On 04/28/2016 07:51 AM, Stian Thorgersen wrote:
>>
>>         First thing would be to create PasswordPolicySPI,
>>         PasswordPolicyProviderFactory
>>         and PasswordPolicyProvider. PasswordPolicyProvider should have
>> same
>>         methods as Policy. You'd then have to extract all built-in
>> providers
>>         from PasswordPolicy into PasswordPolicyProvider implementations,
>>         this
>>         should be relatively straightforward as they are already "id" ->
>>         implementation, just means you retrieve it with KeycloakSession
>>         rather
>>         than hard-coded in PasswordPolicy. PasswordPolicy should then be
>>         change
>>         to use KeycloakSession to retrieve PasswordPolicyProvider instead
>> of
>>         hard-coded Policy implementations.
>>
>>         Next step would be admin console integration. At the moment the
>>         list of
>>         policies is hard-coded it would need to get the list of policies
>>         from
>>         server-info instead. There are other bits that use server-info
>>         to list
>>         providers already so take a look at that. You would probably
>>         also need
>>         to add a method to PasswordPolicyProvider to return a
>>         description of the
>>         policy for the admin console tooltips.
>>
>>         On 25 April 2016 at 18:36, Roelof Naude <roelof.naude at gmail.com
>>         <mailto:roelof.naude at gmail.com>
>>         <mailto:roelof.naude at gmail.com <mailto:roelof.naude at gmail.com>>>
>>         wrote:
>>
>>              thank you all for the quick response.
>>
>>              do you guys have a basic idea on how to approach the policy
>>         spi? we
>>              are more than willing to help out to get it done.
>>
>>              maintaining a fork is maybe an option to resolve the
>>         immediate need,
>>              but would prefer to keep things upstream as much as possible.
>>
>>              On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen
>>              <sthorger at redhat.com <mailto:sthorger at redhat.com>
>>         <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>> wrote:
>>
>>                  We an to introduce a password policy spi soon, but for
>> now
>>                  you're stuck with the built-in policies.
>>
>>                  On 25 Apr 2016 16:43, "Bruno Oliveira"
>>         <bruno at abstractj.org <mailto:bruno at abstractj.org>
>>                  <mailto:bruno at abstractj.org
>>
>>         <mailto:bruno at abstractj.org>>> wrote:
>>
>>                      I believe we don't have an SPI for this, yet. See:
>>         https://issues.jboss.org/browse/KEYCLOAK-2824.
>>
>>                      IMO, Argon2 is completely new and aside from the
>>         bindings,
>>                      we don't have
>>                      a Java implementation, yet for this. I'm not sure
>>         if is a
>>                      good idea to
>>                      introduce C to the codebase, but totally doable to
>>         have an
>>                      SPI for
>>                      policies.
>>
>>                      On 2016-04-25, Roelof Naude wrote:
>>                       > hi,
>>                       >
>>                       > a client has requested the use of the argon2 [1,
>> 2]
>>                      password hashing
>>                       > scheme. this can easily be added as an external
>>         provider.
>>                      we do however
>>                       > require custom password policies, e.g. memory /
>>                      parallelism cost as well as
>>                       > salt length. AFAIK there is no way to provide
>> policy
>>                      extensions using a
>>                       > provider interface?
>>                       >
>>                       > would argon2 be a worthwhile contribution?
>>                       >
>>                       > regards
>>                       > roelof.
>>                       >
>>                       > [1] https://github.com/P-H-C/phc-winner-argon2
>>                       > [2] https://github.com/phxql/argon2-jvm
>>
>>                       > _______________________________________________
>>                       > keycloak-dev mailing list
>>                       > keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>                      <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>
>>                       >
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>                      --
>>
>>                      abstractj
>>                      PGP: 0x84DC9914
>>                      _______________________________________________
>>                      keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org
>> >
>>                      <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/63eb4a04/attachment-0001.html 

From mposolda at redhat.com  Fri Apr 29 05:39:23 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 29 Apr 2016 11:39:23 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <CAJgngAdbwU6ub264YHe6t2w5hidtS5h=vxH6b4OdQ8Mhmaa+0Q@mail.gmail.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
	<CAJgngAfz=fzRFTrTrmxq0q9S6OsxiQZ0NgqBsOi4Na45eVNcdg@mail.gmail.com>
	<CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
	<CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>
	<57232244.90205@redhat.com>
	<CAJgngAdbwU6ub264YHe6t2w5hidtS5h=vxH6b4OdQ8Mhmaa+0Q@mail.gmail.com>
Message-ID: <57232BCB.30804@redhat.com>

On 29/04/16 11:06, Stian Thorgersen wrote:
>
>
> On 29 April 2016 at 10:58, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 29/04/16 10:22, Stian Thorgersen wrote:
>>
>>     We have 3 types of providers:
>>
>>     * Server configured - no config or config from keycloak-server
>>     * Realm configured - config from realm model
>>     * Instance configured - multiple instances per realm
>>
>>     Removing master realm as we plan to do means that realm
>>     configured provider factories can get realm from KeycloakContext
>>     as there's only one realm per-session.
>>
>     In theory yes. In practice there might be still corner cases when
>     you need to deal with multiple realms inside same KeycloakSession
>     (like export/import for example). But hope we can handle most of
>     the cases by assume that KeycloakContext has correct realm set.
>
>
> Corner cases like that is easy - we'd use create a KeycloakSession 
> per-realm, making sure KeycloakContext is initialized properly.
>
>
>>     For instance configured I propose we add getProvider(Class c,
>>     String id, String instanceId) to provider factory. The it's up to
>>     the provider factory itself to extract  the config from the realm
>>     model or another source. It also means that the session can
>>     easily keep track of these and only create one id+instanceId per
>>     session.
>>
>     ah, ok. I somehow missed the proposal.
>
>     It should work fine, I think it's quite similar to what I
>     proposed. Despite I proposed to send whole state to provider
>     factory (aka. UserFederationProviderModel) instead of just
>     instanceId and then assume that state must properly implement
>     "hashCode" to ensure that session can keep track of these and
>     return provider of already used state.
>
>
> Yup, very similar, but I think the devil is in the details. In my 
> proposal the factory itself knows how to extract the state, so it's 
> then up to the factory to decide how state should be stored. A custom 
> provider may need to store config in a separate custom entity, which 
> KeycloakSessionFactory wouldn't know how to retrieve.
Well, for custom SPI providers, you can simply use "String" as the state 
type. Defacto I see the only difference between proposals, that yours is 
simpler as it's just always using "String" as state type instead of 
having type dynamic.


I am not saying it's big issue though. For example UserFederationManager 
now already have all UserFederationProviderModel instances configured 
for realm, so with yours, you will need to call:

session.getProvider(UserFederationProvider.class, "ldap", 
providerModel.getId());

and session will need to load UserFederationProviderModel again from 
realm as it knows just id. But since it's supposed to be cached, there 
is no additional performance penalty in loading 
UserFederationProviderModel again.

So I agree we can try to go simpler way and possibly enhance just if we 
find another SPI limitations.

Marek
>
>
>
>     Marek
>>     On 29 Apr 2016 09:43, "Marek Posolda" <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         Yes, AFAIK we have open JIRA for this for a long time ago.
>>
>>         It's the same issue for IdentityProvider (and maybe some
>>         others SPI too) that they bypass "official" way for create
>>         provider via session.getProvider(providerClazz) and hence
>>         they are not registered in KeycloakSession and "close" method
>>         is not called for them.
>>
>>         The issue is that our SPI is a bit limited IMO and doesn't
>>         support "stateful" providers. The providers are created
>>         through "ProviderFactory.create(KeycloakSession)". So the
>>         only available state of provider ATM is just ProviderFactory
>>         + KeycloakSession, which is sometimes not sufficient.
>>
>>
>>         I can see 2 possibilities to address:
>>
>>         1) Always make the provider implementation "stateless" and
>>         ensure all the state is passed as argument to provider
>>         methods. This is what we already do for some providers (for
>>         example all methods of UserProvider has RealmModel as
>>         parameter). So if we rewrite UserFederation SPI that
>>         UserFederationProviderModel will be passed as argument to all
>>         methods of UserFederationProvider, then it can use "official"
>>         way too.
>>
>>
>>         2) Improve the SPI, so it can properly support "stateful"
>>         providers. This is more flexible then (1) and I would go this
>>         way long term.
>>
>>         I am thinking about something like this:
>>
>>         public interface StatefulProvider<S> extends Provider {
>>         }
>>
>>
>>         public class StatefulProviderFactory<T extends
>>         StatefulProvider, S> {
>>
>>         T create(KeycloakSession session, S state);
>>
>>              .......
>>         }
>>
>>
>>         and on KEycloakSession new method like this:
>>
>>         <S,T extends StatefulProvider<S>>T getProvider(Class<T> providerClazz, String id,S state);
>>
>>
>>         The "state" will need to properly implement equals and
>>         hashCode, so the SPI can deal with it and not create another
>>         instance of StatefulProvider if it was called for this
>>         KeycloakSession with same state before.
>>
>>         Marek
>>
>>
>>
>>         On 29/04/16 08:00, Stian Thorgersen wrote:
>>>         Looking at the code for user federation it looks like user
>>>         federation provider instances with the same configuration
>>>         can be created multiple times for a single session. Also
>>>         they are never closed to resources aren't released.
>>>
>>>
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

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

From mposolda at redhat.com  Fri Apr 29 05:48:31 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 29 Apr 2016 11:48:31 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <57232BCB.30804@redhat.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
	<CAJgngAfz=fzRFTrTrmxq0q9S6OsxiQZ0NgqBsOi4Na45eVNcdg@mail.gmail.com>
	<CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
	<CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>
	<57232244.90205@redhat.com>
	<CAJgngAdbwU6ub264YHe6t2w5hidtS5h=vxH6b4OdQ8Mhmaa+0Q@mail.gmail.com>
	<57232BCB.30804@redhat.com>
Message-ID: <57232DEF.8040702@redhat.com>

On 29/04/16 11:39, Marek Posolda wrote:
> On 29/04/16 11:06, Stian Thorgersen wrote:
>>
>>
>> On 29 April 2016 at 10:58, Marek Posolda <mposolda at redhat.com 
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>     On 29/04/16 10:22, Stian Thorgersen wrote:
>>>
>>>     We have 3 types of providers:
>>>
>>>     * Server configured - no config or config from keycloak-server
>>>     * Realm configured - config from realm model
>>>     * Instance configured - multiple instances per realm
>>>
>>>     Removing master realm as we plan to do means that realm
>>>     configured provider factories can get realm from KeycloakContext
>>>     as there's only one realm per-session.
>>>
>>     In theory yes. In practice there might be still corner cases when
>>     you need to deal with multiple realms inside same KeycloakSession
>>     (like export/import for example). But hope we can handle most of
>>     the cases by assume that KeycloakContext has correct realm set.
>>
>>
>> Corner cases like that is easy - we'd use create a KeycloakSession 
>> per-realm, making sure KeycloakContext is initialized properly.
>>
>>
>>>     For instance configured I propose we add getProvider(Class c,
>>>     String id, String instanceId) to provider factory. The it's up
>>>     to the provider factory itself to extract  the config from the
>>>     realm model or another source. It also means that the session
>>>     can easily keep track of these and only create one id+instanceId
>>>     per session.
>>>
>>     ah, ok. I somehow missed the proposal.
>>
>>     It should work fine, I think it's quite similar to what I
>>     proposed. Despite I proposed to send whole state to provider
>>     factory (aka. UserFederationProviderModel) instead of just
>>     instanceId and then assume that state must properly implement
>>     "hashCode" to ensure that session can keep track of these and
>>     return provider of already used state.
>>
>>
>> Yup, very similar, but I think the devil is in the details. In my 
>> proposal the factory itself knows how to extract the state, so it's 
>> then up to the factory to decide how state should be stored. A custom 
>> provider may need to store config in a separate custom entity, which 
>> KeycloakSessionFactory wouldn't know how to retrieve.
> Well, for custom SPI providers, you can simply use "String" as the 
> state type. Defacto I see the only difference between proposals, that 
> yours is simpler as it's just always using "String" as state type 
> instead of having type dynamic.
>
>
> I am not saying it's big issue though. For example 
> UserFederationManager now already have all UserFederationProviderModel 
> instances configured for realm, so with yours, you will need to call:
>
> session.getProvider(UserFederationProvider.class, "ldap", 
> providerModel.getId());
>
> and session will need to load UserFederationProviderModel again from 
> realm as it knows just id. But since it's supposed to be cached, there 
> is no additional performance penalty in loading 
> UserFederationProviderModel again.
Well ;-)

But on the other hand with simpler proposal... All 
UserFederationProviderFactory implementations provided by people will 
always need to load UserFederationProviderModel at the beginning:

UserFederationProviderModel providerModel = 
session.getContext().getRealm().getFederationProvider(id);

so there is some shared logic, which can be possibly handled by 
keycloak, but with simpler proposal, people will always need to call 
this in their UserFederationProviderFactory implementations.

Marek
>
> So I agree we can try to go simpler way and possibly enhance just if 
> we find another SPI limitations.
>
> Marek
>>
>>
>>
>>     Marek
>>>     On 29 Apr 2016 09:43, "Marek Posolda" <mposolda at redhat.com
>>>     <mailto:mposolda at redhat.com>> wrote:
>>>
>>>         Yes, AFAIK we have open JIRA for this for a long time ago.
>>>
>>>         It's the same issue for IdentityProvider (and maybe some
>>>         others SPI too) that they bypass "official" way for create
>>>         provider via session.getProvider(providerClazz) and hence
>>>         they are not registered in KeycloakSession and "close"
>>>         method is not called for them.
>>>
>>>         The issue is that our SPI is a bit limited IMO and doesn't
>>>         support "stateful" providers. The providers are created
>>>         through "ProviderFactory.create(KeycloakSession)". So the
>>>         only available state of provider ATM is just ProviderFactory
>>>         + KeycloakSession, which is sometimes not sufficient.
>>>
>>>
>>>         I can see 2 possibilities to address:
>>>
>>>         1) Always make the provider implementation "stateless" and
>>>         ensure all the state is passed as argument to provider
>>>         methods. This is what we already do for some providers (for
>>>         example all methods of UserProvider has RealmModel as
>>>         parameter). So if we rewrite UserFederation SPI that
>>>         UserFederationProviderModel will be passed as argument to
>>>         all methods of UserFederationProvider, then it can use
>>>         "official" way too.
>>>
>>>
>>>         2) Improve the SPI, so it can properly support "stateful"
>>>         providers. This is more flexible then (1) and I would go
>>>         this way long term.
>>>
>>>         I am thinking about something like this:
>>>
>>>         public interface StatefulProvider<S> extends Provider {
>>>         }
>>>
>>>
>>>         public class StatefulProviderFactory<T extends
>>>         StatefulProvider, S> {
>>>
>>>         T create(KeycloakSession session, S state);
>>>
>>>              .......
>>>         }
>>>
>>>
>>>         and on KEycloakSession new method like this:
>>>
>>>         <S,T extends StatefulProvider<S>>T getProvider(Class<T> providerClazz, String id,S state);
>>>
>>>
>>>         The "state" will need to properly implement equals and
>>>         hashCode, so the SPI can deal with it and not create another
>>>         instance of StatefulProvider if it was called for this
>>>         KeycloakSession with same state before.
>>>
>>>         Marek
>>>
>>>
>>>
>>>         On 29/04/16 08:00, Stian Thorgersen wrote:
>>>>         Looking at the code for user federation it looks like user
>>>>         federation provider instances with the same configuration
>>>>         can be created multiple times for a single session. Also
>>>>         they are never closed to resources aren't released.
>>>>
>>>>
>>>>         _______________________________________________
>>>>         keycloak-dev mailing list
>>>>         keycloak-dev at lists.jboss.org
>>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Fri Apr 29 06:42:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 12:42:48 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <57232DEF.8040702@redhat.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
	<CAJgngAfz=fzRFTrTrmxq0q9S6OsxiQZ0NgqBsOi4Na45eVNcdg@mail.gmail.com>
	<CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
	<CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>
	<57232244.90205@redhat.com>
	<CAJgngAdbwU6ub264YHe6t2w5hidtS5h=vxH6b4OdQ8Mhmaa+0Q@mail.gmail.com>
	<57232BCB.30804@redhat.com> <57232DEF.8040702@redhat.com>
Message-ID: <CAJgngAeo9_ykym7PG-yxG3gaW74fgrrLaNpx8NhR3sRCc1iDBw@mail.gmail.com>

On 29 April 2016 at 11:48, Marek Posolda <mposolda at redhat.com> wrote:

> On 29/04/16 11:39, Marek Posolda wrote:
>
> On 29/04/16 11:06, Stian Thorgersen wrote:
>
>
>
> On 29 April 2016 at 10:58, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 29/04/16 10:22, Stian Thorgersen wrote:
>>
>> We have 3 types of providers:
>>
>> * Server configured - no config or config from keycloak-server
>> * Realm configured - config from realm model
>> * Instance configured - multiple instances per realm
>>
>> Removing master realm as we plan to do means that realm configured
>> provider factories can get realm from KeycloakContext as there's only one
>> realm per-session.
>>
>> In theory yes. In practice there might be still corner cases when you
>> need to deal with multiple realms inside same KeycloakSession (like
>> export/import for example). But hope we can handle most of the cases by
>> assume that KeycloakContext has correct realm set.
>>
>
> Corner cases like that is easy - we'd use create a KeycloakSession
> per-realm, making sure KeycloakContext is initialized properly.
>
>
>>
>> For instance configured I propose we add getProvider(Class c, String id,
>> String instanceId) to provider factory. The it's up to the provider factory
>> itself to extract  the config from the realm model or another source. It
>> also means that the session can easily keep track of these and only create
>> one id+instanceId per session.
>>
>> ah, ok. I somehow missed the proposal.
>>
>> It should work fine, I think it's quite similar to what I proposed.
>> Despite I proposed to send whole state to provider factory (aka.
>> UserFederationProviderModel) instead of just instanceId and then assume
>> that state must properly implement "hashCode" to ensure that session can
>> keep track of these and return provider of already used state.
>>
>
> Yup, very similar, but I think the devil is in the details. In my proposal
> the factory itself knows how to extract the state, so it's then up to the
> factory to decide how state should be stored. A custom provider may need to
> store config in a separate custom entity, which KeycloakSessionFactory
> wouldn't know how to retrieve.
>
> Well, for custom SPI providers, you can simply use "String" as the state
> type. Defacto I see the only difference between proposals, that yours is
> simpler as it's just always using "String" as state type instead of having
> type dynamic.
>
>
> I am not saying it's big issue though. For example UserFederationManager
> now already have all UserFederationProviderModel instances configured for
> realm, so with yours, you will need to call:
>
> session.getProvider(UserFederationProvider.class, "ldap",
> providerModel.getId());
>
> and session will need to load UserFederationProviderModel again from realm
> as it knows just id. But since it's supposed to be cached, there is no
> additional performance penalty in loading UserFederationProviderModel again.
>
> Well ;-)
>
> But on the other hand with simpler proposal... All
> UserFederationProviderFactory implementations provided by people will
> always need to load UserFederationProviderModel at the beginning:
>
> UserFederationProviderModel providerModel =
> session.getContext().getRealm().getFederationProvider(id);
>
> so there is some shared logic, which can be possibly handled by keycloak,
> but with simpler proposal, people will always need to call this in their
> UserFederationProviderFactory implementations.
>

Depends. Should the "caller" actually load the UserFederationProviderModel
at all? It seems like all the caller needs to know is the instanceId and
shouldn't need to deal with loading the model/config.

Another thing, but that would require db changes for sure, could we have a
generic configuration mechanism? So rather than having to create a table
for each SPI we could have a single providers table. That would make it
much easier to introduce new SPIs.


>
>
> Marek
>
>
> So I agree we can try to go simpler way and possibly enhance just if we
> find another SPI limitations.
>
> Marek
>
>
>
>>
>>
>> Marek
>>
>> On 29 Apr 2016 09:43, "Marek Posolda" <mposolda at redhat.com> wrote:
>>
>> Yes, AFAIK we have open JIRA for this for a long time ago.
>>
>> It's the same issue for IdentityProvider (and maybe some others SPI too)
>> that they bypass "official" way for create provider via
>> session.getProvider(providerClazz) and hence they are not registered in
>> KeycloakSession and "close" method is not called for them.
>>
>> The issue is that our SPI is a bit limited IMO and doesn't support
>> "stateful" providers. The providers are created through
>> "ProviderFactory.create(KeycloakSession)". So the only available state of
>> provider ATM is just ProviderFactory + KeycloakSession, which is sometimes
>> not sufficient.
>>
>>
>> I can see 2 possibilities to address:
>>
>> 1) Always make the provider implementation "stateless" and ensure all the
>> state is passed as argument to provider methods. This is what we already do
>> for some providers (for example all methods of UserProvider has RealmModel
>> as parameter). So if we rewrite UserFederation SPI that
>> UserFederationProviderModel will be passed as argument to all methods of
>> UserFederationProvider, then it can use "official" way too.
>>
>>
>> 2) Improve the SPI, so it can properly support "stateful" providers. This
>> is more flexible then (1) and I would go this way long term.
>>
>> I am thinking about something like this:
>>
>> public interface StatefulProvider<S> extends Provider {
>> }
>>
>>
>> public class StatefulProviderFactory<T extends StatefulProvider, S> {
>>
>>      T create(KeycloakSession session, S state);
>>
>>      .......
>> }
>>
>>
>> and on KEycloakSession new method like this:
>>
>> <S, T extends StatefulProvider<S>> T getProvider(Class<T> providerClazz, String id, S state);
>>
>>
>> The "state" will need to properly implement equals and hashCode, so the
>> SPI can deal with it and not create another instance of StatefulProvider if
>> it was called for this KeycloakSession with same state before.
>>
>> Marek
>>
>>
>>
>> On 29/04/16 08:00, Stian Thorgersen wrote:
>>
>> Looking at the code for user federation it looks like user federation
>> provider instances with the same configuration can be created multiple
>> times for a single session. Also they are never closed to resources aren't
>> released.
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/4ea54e40/attachment.html 

From Marcus.May at bedag.ch  Fri Apr 29 07:15:11 2016
From: Marcus.May at bedag.ch (May Marcus, Bedag)
Date: Fri, 29 Apr 2016 11:15:11 +0000
Subject: [keycloak-dev] SSO does not work if more than one federation
 provider (ldap with kerberos) is registered
Message-ID: <3835837561142448A72F035FFA6D0BAD010010F4B7@bisrv1040.ad.bedag.ch>

Hi, I would like to propose an enhancement to the selection of an federation provider (ldap with kerberos).

I tried to register two federation providers (ldap with kerberos) to support SSO for users in two different kerberos realms. The problem is that only the first (according to attribute priority) will be used to authenticate the user. Authentication of users from the other federation provider with kerberos does not work.

I think the selection of the federation provider to use could be improved in the code to solve this issue. I found the following code fragment in "org.keycloak.models.UserFederationManager.validCredentials(KeycloakSession, RealmModel, UserCredentialModel...)":

// Find first provider, which supports required credential type
for (UserFederationProvider fedProvider : fedProviders) {
        if (fedProvider.getSupportedCredentialTypes().contains(cred.getType())) {
                providerSupportingCreds = fedProvider;
                break;
        }
}

In case of kerberos the federation provider could be chosen based on the kerberos realm in the ticket and the configured kerberos realm.

Can I just create an issue of type enhancement in jira?

Marcus


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

From mposolda at redhat.com  Fri Apr 29 07:16:17 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 29 Apr 2016 13:16:17 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <CAJgngAeo9_ykym7PG-yxG3gaW74fgrrLaNpx8NhR3sRCc1iDBw@mail.gmail.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
	<CAJgngAfz=fzRFTrTrmxq0q9S6OsxiQZ0NgqBsOi4Na45eVNcdg@mail.gmail.com>
	<CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
	<CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>
	<57232244.90205@redhat.com>
	<CAJgngAdbwU6ub264YHe6t2w5hidtS5h=vxH6b4OdQ8Mhmaa+0Q@mail.gmail.com>
	<57232BCB.30804@redhat.com> <57232DEF.8040702@redhat.com>
	<CAJgngAeo9_ykym7PG-yxG3gaW74fgrrLaNpx8NhR3sRCc1iDBw@mail.gmail.com>
Message-ID: <57234281.4030109@redhat.com>

On 29/04/16 12:42, Stian Thorgersen wrote:
>
>
> On 29 April 2016 at 11:48, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 29/04/16 11:39, Marek Posolda wrote:
>>     On 29/04/16 11:06, Stian Thorgersen wrote:
>>>
>>>
>>>     On 29 April 2016 at 10:58, Marek Posolda <mposolda at redhat.com
>>>     <mailto:mposolda at redhat.com>> wrote:
>>>
>>>         On 29/04/16 10:22, Stian Thorgersen wrote:
>>>>
>>>>         We have 3 types of providers:
>>>>
>>>>         * Server configured - no config or config from keycloak-server
>>>>         * Realm configured - config from realm model
>>>>         * Instance configured - multiple instances per realm
>>>>
>>>>         Removing master realm as we plan to do means that realm
>>>>         configured provider factories can get realm from
>>>>         KeycloakContext as there's only one realm per-session.
>>>>
>>>         In theory yes. In practice there might be still corner cases
>>>         when you need to deal with multiple realms inside same
>>>         KeycloakSession (like export/import for example). But hope
>>>         we can handle most of the cases by assume that
>>>         KeycloakContext has correct realm set.
>>>
>>>
>>>     Corner cases like that is easy - we'd use create a
>>>     KeycloakSession per-realm, making sure KeycloakContext is
>>>     initialized properly.
>>>
>>>
>>>>         For instance configured I propose we add getProvider(Class
>>>>         c, String id, String instanceId) to provider factory. The
>>>>         it's up to the provider factory itself to extract  the
>>>>         config from the realm model or another source. It also
>>>>         means that the session can easily keep track of these and
>>>>         only create one id+instanceId per session.
>>>>
>>>         ah, ok. I somehow missed the proposal.
>>>
>>>         It should work fine, I think it's quite similar to what I
>>>         proposed. Despite I proposed to send whole state to provider
>>>         factory (aka. UserFederationProviderModel) instead of just
>>>         instanceId and then assume that state must properly
>>>         implement "hashCode" to ensure that session can keep track
>>>         of these and return provider of already used state.
>>>
>>>
>>>     Yup, very similar, but I think the devil is in the details. In
>>>     my proposal the factory itself knows how to extract the state,
>>>     so it's then up to the factory to decide how state should be
>>>     stored. A custom provider may need to store config in a separate
>>>     custom entity, which KeycloakSessionFactory wouldn't know how to
>>>     retrieve.
>>     Well, for custom SPI providers, you can simply use "String" as
>>     the state type. Defacto I see the only difference between
>>     proposals, that yours is simpler as it's just always using
>>     "String" as state type instead of having type dynamic.
>>
>>
>>     I am not saying it's big issue though. For example
>>     UserFederationManager now already have all
>>     UserFederationProviderModel instances configured for realm, so
>>     with yours, you will need to call:
>>
>>     session.getProvider(UserFederationProvider.class, "ldap",
>>     providerModel.getId());
>>
>>     and session will need to load UserFederationProviderModel again
>>     from realm as it knows just id. But since it's supposed to be
>>     cached, there is no additional performance penalty in loading
>>     UserFederationProviderModel again.
>     Well ;-)
>
>     But on the other hand with simpler proposal... All
>     UserFederationProviderFactory implementations provided by people
>     will always need to load UserFederationProviderModel at the beginning:
>
>     UserFederationProviderModel providerModel =
>     session.getContext().getRealm().getFederationProvider(id);
>
>     so there is some shared logic, which can be possibly handled by
>     keycloak, but with simpler proposal, people will always need to
>     call this in their UserFederationProviderFactory implementations.
>
>
> Depends. Should the "caller" actually load the 
> UserFederationProviderModel at all? It seems like all the caller needs 
> to know is the instanceId and shouldn't need to deal with loading the 
> model/config.
Yeah, we can change the "caller" ( UserFederationManager ) to load just 
id. The UserModel has just "federationLink" with the ID, so we don't 
need to load the full UserFederationProviderModel in 
UserFederationManager. During registration or lookup new user, you need 
a list of full provider models though as they need to be sorted by 
priority. But that's very minor....

There is still also the second minor issue I mentioned above, that 
UserFederationProvider implementation always needs 
UserFederationProviderModel (besides some simple impl, which don't have 
any custom config). So in many cases the 
UserFederationProviderFactory.create implementations will always start 
with load of UserFederationProviderModel as they have only ID. So that's 
common logic, which can be theoretically handled by our SPI framework 
instead. But also quite minor though...

I don't have strong opinion that simpler proposal with "String" is not 
enough.
> Another thing, but that would require db changes for sure, could we 
> have a generic configuration mechanism? So rather than having to 
> create a table for each SPI we could have a single providers table. 
> That would make it much easier to introduce new SPIs.
+1

Marek
>
>
>
>     Marek
>
>>
>>     So I agree we can try to go simpler way and possibly enhance just
>>     if we find another SPI limitations.
>>
>>     Marek
>>>
>>>
>>>
>>>         Marek
>>>>         On 29 Apr 2016 09:43, "Marek Posolda" <mposolda at redhat.com
>>>>         <mailto:mposolda at redhat.com>> wrote:
>>>>
>>>>             Yes, AFAIK we have open JIRA for this for a long time ago.
>>>>
>>>>             It's the same issue for IdentityProvider (and maybe
>>>>             some others SPI too) that they bypass "official" way
>>>>             for create provider via
>>>>             session.getProvider(providerClazz) and hence they are
>>>>             not registered in KeycloakSession and "close" method is
>>>>             not called for them.
>>>>
>>>>             The issue is that our SPI is a bit limited IMO and
>>>>             doesn't support "stateful" providers. The providers are
>>>>             created through
>>>>             "ProviderFactory.create(KeycloakSession)". So the only
>>>>             available state of provider ATM is just ProviderFactory
>>>>             + KeycloakSession, which is sometimes not sufficient.
>>>>
>>>>
>>>>             I can see 2 possibilities to address:
>>>>
>>>>             1) Always make the provider implementation "stateless"
>>>>             and ensure all the state is passed as argument to
>>>>             provider methods. This is what we already do for some
>>>>             providers (for example all methods of UserProvider has
>>>>             RealmModel as parameter). So if we rewrite
>>>>             UserFederation SPI that UserFederationProviderModel
>>>>             will be passed as argument to all methods of
>>>>             UserFederationProvider, then it can use "official" way
>>>>             too.
>>>>
>>>>
>>>>             2) Improve the SPI, so it can properly support
>>>>             "stateful" providers. This is more flexible then (1)
>>>>             and I would go this way long term.
>>>>
>>>>             I am thinking about something like this:
>>>>
>>>>             public interface StatefulProvider<S> extends Provider {
>>>>             }
>>>>
>>>>
>>>>             public class StatefulProviderFactory<T extends
>>>>             StatefulProvider, S> {
>>>>
>>>>             T create(KeycloakSession session, S state);
>>>>
>>>>                  .......
>>>>             }
>>>>
>>>>
>>>>             and on KEycloakSession new method like this:
>>>>
>>>>             <S,T extends StatefulProvider<S>>T getProvider(Class<T> providerClazz, String id,S state);
>>>>
>>>>
>>>>             The "state" will need to properly implement equals and
>>>>             hashCode, so the SPI can deal with it and not create
>>>>             another instance of StatefulProvider if it was called
>>>>             for this KeycloakSession with same state before.
>>>>
>>>>             Marek
>>>>
>>>>
>>>>
>>>>             On 29/04/16 08:00, Stian Thorgersen wrote:
>>>>>             Looking at the code for user federation it looks like
>>>>>             user federation provider instances with the same
>>>>>             configuration can be created multiple times for a
>>>>>             single session. Also they are never closed to
>>>>>             resources aren't released.
>>>>>
>>>>>
>>>>>             _______________________________________________
>>>>>             keycloak-dev mailing list
>>>>>             keycloak-dev at lists.jboss.org
>>>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From mposolda at redhat.com  Fri Apr 29 07:43:12 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 29 Apr 2016 13:43:12 +0200
Subject: [keycloak-dev] SSO does not work if more than one federation
 provider (ldap with kerberos) is registered
In-Reply-To: <3835837561142448A72F035FFA6D0BAD010010F4B7@bisrv1040.ad.bedag.ch>
References: <3835837561142448A72F035FFA6D0BAD010010F4B7@bisrv1040.ad.bedag.ch>
Message-ID: <572348D0.6030305@redhat.com>

On 29/04/16 13:15, May Marcus, Bedag wrote:
> Hi, I would like to propose an enhancement to the selection of an 
> federation provider (ldap with kerberos).
> I tried to register two federation providers (ldap with kerberos) to 
> support SSO for users in two different kerberos realms. The problem is 
> that only the first (according to attribute priority) will be used to 
> authenticate the user. Authentication of users from the other 
> federation provider with kerberos does not work.
> I think the selection of the federation provider to use could be 
> improved in the code to solve this issue. I found the following code 
> fragment in 
> "org.keycloak.models.UserFederationManager.validCredentials(KeycloakSession, 
> RealmModel, UserCredentialModel...)":
> // Find first provider, which supports required credential type
> for (UserFederationProvider fedProvider : fedProviders) {
>         if 
> (fedProvider.getSupportedCredentialTypes().contains(cred.getType())) {
> providerSupportingCreds = fedProvider;
> break;
>         }
> }
> In case of kerberos the federation provider could be chosen based on 
> the kerberos realm in the ticket and the configured kerberos realm.
> Can I just create an issue of type enhancement in jira?
Yes,feel free to create JIRA for that.

Marek
> Marcus
>
>
> _______________________________________________
> 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/20160429/30155134/attachment.html 

From sthorger at redhat.com  Fri Apr 29 07:49:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Apr 2016 13:49:47 +0200
Subject: [keycloak-dev] User Federation provider instances
In-Reply-To: <57234281.4030109@redhat.com>
References: <CAJgngAd9YnZ=eJS9Z1uQD+Hsg+zysTCyLBJHDp0Xz3WdYAo=HA@mail.gmail.com>
	<572310BA.4060904@redhat.com>
	<CAJgngAfz=fzRFTrTrmxq0q9S6OsxiQZ0NgqBsOi4Na45eVNcdg@mail.gmail.com>
	<CAJgngAdbyJPNZs=_mKCSPS-dqqiu+M-yPvxH=dOgyQpRyhxyaA@mail.gmail.com>
	<CAJgngAd_Y0LnNG9KEGUiON=yZqC=qMtPJ59bBg8t9SPKXBUQcQ@mail.gmail.com>
	<57232244.90205@redhat.com>
	<CAJgngAdbwU6ub264YHe6t2w5hidtS5h=vxH6b4OdQ8Mhmaa+0Q@mail.gmail.com>
	<57232BCB.30804@redhat.com> <57232DEF.8040702@redhat.com>
	<CAJgngAeo9_ykym7PG-yxG3gaW74fgrrLaNpx8NhR3sRCc1iDBw@mail.gmail.com>
	<57234281.4030109@redhat.com>
Message-ID: <CAJgngAeZHBhaKjyeXCDwSYH+WNRFijU0zsb6-bdtuKpwHzsrdA@mail.gmail.com>

On 29 April 2016 at 13:16, Marek Posolda <mposolda at redhat.com> wrote:

> On 29/04/16 12:42, Stian Thorgersen wrote:
>
>
>
> On 29 April 2016 at 11:48, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 29/04/16 11:39, Marek Posolda wrote:
>>
>> On 29/04/16 11:06, Stian Thorgersen wrote:
>>
>>
>>
>> On 29 April 2016 at 10:58, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> On 29/04/16 10:22, Stian Thorgersen wrote:
>>>
>>> We have 3 types of providers:
>>>
>>> * Server configured - no config or config from keycloak-server
>>> * Realm configured - config from realm model
>>> * Instance configured - multiple instances per realm
>>>
>>> Removing master realm as we plan to do means that realm configured
>>> provider factories can get realm from KeycloakContext as there's only one
>>> realm per-session.
>>>
>>> In theory yes. In practice there might be still corner cases when you
>>> need to deal with multiple realms inside same KeycloakSession (like
>>> export/import for example). But hope we can handle most of the cases by
>>> assume that KeycloakContext has correct realm set.
>>>
>>
>> Corner cases like that is easy - we'd use create a KeycloakSession
>> per-realm, making sure KeycloakContext is initialized properly.
>>
>>
>>>
>>> For instance configured I propose we add getProvider(Class c, String id,
>>> String instanceId) to provider factory. The it's up to the provider factory
>>> itself to extract  the config from the realm model or another source. It
>>> also means that the session can easily keep track of these and only create
>>> one id+instanceId per session.
>>>
>>> ah, ok. I somehow missed the proposal.
>>>
>>> It should work fine, I think it's quite similar to what I proposed.
>>> Despite I proposed to send whole state to provider factory (aka.
>>> UserFederationProviderModel) instead of just instanceId and then assume
>>> that state must properly implement "hashCode" to ensure that session can
>>> keep track of these and return provider of already used state.
>>>
>>
>> Yup, very similar, but I think the devil is in the details. In my
>> proposal the factory itself knows how to extract the state, so it's then up
>> to the factory to decide how state should be stored. A custom provider may
>> need to store config in a separate custom entity, which
>> KeycloakSessionFactory wouldn't know how to retrieve.
>>
>> Well, for custom SPI providers, you can simply use "String" as the state
>> type. Defacto I see the only difference between proposals, that yours is
>> simpler as it's just always using "String" as state type instead of having
>> type dynamic.
>>
>>
>> I am not saying it's big issue though. For example UserFederationManager
>> now already have all UserFederationProviderModel instances configured for
>> realm, so with yours, you will need to call:
>>
>> session.getProvider(UserFederationProvider.class, "ldap",
>> providerModel.getId());
>>
>> and session will need to load UserFederationProviderModel again from
>> realm as it knows just id. But since it's supposed to be cached, there is
>> no additional performance penalty in loading UserFederationProviderModel
>> again.
>>
>> Well ;-)
>>
>> But on the other hand with simpler proposal... All
>> UserFederationProviderFactory implementations provided by people will
>> always need to load UserFederationProviderModel at the beginning:
>>
>> UserFederationProviderModel providerModel =
>> session.getContext().getRealm().getFederationProvider(id);
>>
>> so there is some shared logic, which can be possibly handled by keycloak,
>> but with simpler proposal, people will always need to call this in their
>> UserFederationProviderFactory implementations.
>>
>
> Depends. Should the "caller" actually load the UserFederationProviderModel
> at all? It seems like all the caller needs to know is the instanceId and
> shouldn't need to deal with loading the model/config.
>
> Yeah, we can change the "caller" ( UserFederationManager ) to load just
> id. The UserModel has just "federationLink" with the ID, so we don't need
> to load the full UserFederationProviderModel in UserFederationManager.
> During registration or lookup new user, you need a list of full provider
> models though as they need to be sorted by priority. But that's very
> minor....
>
> There is still also the second minor issue I mentioned above, that
> UserFederationProvider implementation always needs
> UserFederationProviderModel (besides some simple impl, which don't have any
> custom config). So in many cases the UserFederationProviderFactory.create
> implementations will always start with load of UserFederationProviderModel
> as they have only ID. So that's common logic, which can be theoretically
> handled by our SPI framework instead. But also quite minor though...
>

Yes, it common in UserFederation, but other SPIs have different mechanisms.
So in that case the SPI would have to load the UserFederationProviderModel,
that could work as well though. It's not a big deal though and I think
having the provider itself responsible for loading is more flexible. One
provider may not want to use UserFederationProviderModel, but instead use
another model or even another store completely.


>
> I don't have strong opinion that simpler proposal with "String" is not
> enough.
>
> Another thing, but that would require db changes for sure, could we have a
> generic configuration mechanism? So rather than having to create a table
> for each SPI we could have a single providers table. That would make it
> much easier to introduce new SPIs.
>
> +1
>
> Marek
>
>
>
>>
>>
>> Marek
>>
>>
>> So I agree we can try to go simpler way and possibly enhance just if we
>> find another SPI limitations.
>>
>> Marek
>>
>>
>>
>>>
>>>
>>> Marek
>>>
>>> On 29 Apr 2016 09:43, "Marek Posolda" < <mposolda at redhat.com>
>>> mposolda at redhat.com> wrote:
>>>
>>> Yes, AFAIK we have open JIRA for this for a long time ago.
>>>
>>> It's the same issue for IdentityProvider (and maybe some others SPI too)
>>> that they bypass "official" way for create provider via
>>> session.getProvider(providerClazz) and hence they are not registered in
>>> KeycloakSession and "close" method is not called for them.
>>>
>>> The issue is that our SPI is a bit limited IMO and doesn't support
>>> "stateful" providers. The providers are created through
>>> "ProviderFactory.create(KeycloakSession)". So the only available state of
>>> provider ATM is just ProviderFactory + KeycloakSession, which is sometimes
>>> not sufficient.
>>>
>>>
>>> I can see 2 possibilities to address:
>>>
>>> 1) Always make the provider implementation "stateless" and ensure all
>>> the state is passed as argument to provider methods. This is what we
>>> already do for some providers (for example all methods of UserProvider has
>>> RealmModel as parameter). So if we rewrite UserFederation SPI that
>>> UserFederationProviderModel will be passed as argument to all methods of
>>> UserFederationProvider, then it can use "official" way too.
>>>
>>>
>>> 2) Improve the SPI, so it can properly support "stateful" providers.
>>> This is more flexible then (1) and I would go this way long term.
>>>
>>> I am thinking about something like this:
>>>
>>> public interface StatefulProvider<S> extends Provider {
>>> }
>>>
>>>
>>> public class StatefulProviderFactory<T extends StatefulProvider, S> {
>>>
>>>      T create(KeycloakSession session, S state);
>>>
>>>      .......
>>> }
>>>
>>>
>>> and on KEycloakSession new method like this:
>>>
>>> <S, T extends StatefulProvider<S>> T getProvider(Class<T> providerClazz, String id, S state);
>>>
>>>
>>> The "state" will need to properly implement equals and hashCode, so the
>>> SPI can deal with it and not create another instance of StatefulProvider if
>>> it was called for this KeycloakSession with same state before.
>>>
>>> Marek
>>>
>>>
>>>
>>> On 29/04/16 08:00, Stian Thorgersen wrote:
>>>
>>> Looking at the code for user federation it looks like user federation
>>> provider instances with the same configuration can be created multiple
>>> times for a single session. Also they are never closed to resources aren't
>>> released.
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/4994b35c/attachment-0001.html 

From roelof.naude at gmail.com  Fri Apr 29 08:48:13 2016
From: roelof.naude at gmail.com (Roelof Naude)
Date: Fri, 29 Apr 2016 14:48:13 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <CAJgngAdmn39t3eG7jjkQCXJ6FBwUq6PP=rLUvfMqNF9gJG99xw@mail.gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>	<20160425144249.GB29202@abstractj.org>	<CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>	<CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>	<CAJgngAcm0hKRVpwzhEr_DVzN+BZQ-OAWSOAYKCBaCFEmS2L8DA@mail.gmail.com>	<5722121C.3030107@gmail.com>	<CAJgngAeasPJWDsp1rUsSMReZE=tcQm_X_rJJc6bNgKUsGYY47g@mail.gmail.com>	<572311B5.30504@gmail.com>
	<CAJgngAdmn39t3eG7jjkQCXJ6FBwUq6PP=rLUvfMqNF9gJG99xw@mail.gmail.com>
Message-ID: <5723580D.20700@gmail.com>

thank you, that helped.

got the first round of changes done. some test cases are now failing. 
this is due to PasswordPolicy loading the PasswordPolicyProvider 
implementations. looks like the KeycloakSessionFactory::init was not 
called. factoriesMap is null.

probably due to more setup / config needed. had a look at some of the 
provider tests (CustomIdentityProvider) but did not spot anything specific.

do you have any hints?

On 04/29/2016 11:10 AM, Stian Thorgersen wrote:
> Pass in PasswordPolicy then. PasswordPolicy can store the config in the
> correct format. getInt(String provider) would parse string and store as
> an int in a map.
>
> This can be improved later, we're currently having a separate discussion
> about adding something like this. Ideally password policies would also
> support more advanced configuration like authenticators, mappers, etc
> already do. That on the other side is more work. If you want to do
> something like what they do that would be great though.
>
> On 29 April 2016 at 09:48, Roelof Naude <roelof.naude at gmail.com
> <mailto:roelof.naude at gmail.com>> wrote:
>
>     hi,
>
>     adding the config to the verify / validate method makes no sense.
>     take for instance HashIterations. it needs to keep the config for
>     later when the password encode takes place. PasswordPolicy::validate
>     is called after construction of the policies...at a time when the
>     configuration has been parsed already. re-parsing the config for
>     every validate can be expensive.
>
>     PasswordPolicyProvider implementations will most likely not access
>     external resources. granted, one cannot foresee all future usage
>     patterns either.
>
>     On 04/29/2016 07:58 AM, Stian Thorgersen wrote:
>
>         Simplest option is to simply add the config to the verify method.
>
>         We have some other SPIs that have more than one instance of a given
>         provider per-realm, but as you say they're not associated with the
>         session. This could cause them not to be closed, or to have multiple
>         instances with same config created per-session.
>
>         On 28 April 2016 at 15:37, Roelof Naude <roelof.naude at gmail.com
>         <mailto:roelof.naude at gmail.com>
>         <mailto:roelof.naude at gmail.com <mailto:roelof.naude at gmail.com>>>
>         wrote:
>
>              thank you. have made some headway with this.
>
>              there is a slight issue though. Providers are cached and
>         thus mostly
>              stateless.
>
>              password policies on the other hand are constructed
>         on-demand and
>              may contain configuration. this configuration can be different
>              between various realms, e.g. HashIterations could be 20 for
>         realm1
>              and 200 for realm2.
>
>              the current provider loading mechanisms caches both the
>         factory and
>              provider instances.
>
>              1. is there a session instance per realm? if so, then there
>         is no issue
>              2. if not, how do you propose creating policy instances per
>         realm?
>
>              PasswordPolicyFactory could expose an extra method,
>         create(String
>              arg), but the provider loading mechanism will ignore it.
>         one could
>              add specific knowledge of that method, but that feels wrong.
>
>              another option would be to teach KeycloakSession to return a
>              ProviderFactory instance. PasswordPolicy could call this
>         method to
>              create PasswordPolicyProvider instances on-demand. this
>         method would
>              delegate to the underlying KeycloakSessonFactory to lookup the
>              appropriate factory.
>
>              this last option could work. would prefer to clear it with
>         you guys
>              first though.
>
>              On 04/28/2016 07:51 AM, Stian Thorgersen wrote:
>
>                  First thing would be to create PasswordPolicySPI,
>                  PasswordPolicyProviderFactory
>                  and PasswordPolicyProvider. PasswordPolicyProvider
>         should have same
>                  methods as Policy. You'd then have to extract all
>         built-in providers
>                  from PasswordPolicy into PasswordPolicyProvider
>         implementations,
>                  this
>                  should be relatively straightforward as they are
>         already "id" ->
>                  implementation, just means you retrieve it with
>         KeycloakSession
>                  rather
>                  than hard-coded in PasswordPolicy. PasswordPolicy
>         should then be
>                  change
>                  to use KeycloakSession to retrieve
>         PasswordPolicyProvider instead of
>                  hard-coded Policy implementations.
>
>                  Next step would be admin console integration. At the
>         moment the
>                  list of
>                  policies is hard-coded it would need to get the list of
>         policies
>                  from
>                  server-info instead. There are other bits that use
>         server-info
>                  to list
>                  providers already so take a look at that. You would
>         probably
>                  also need
>                  to add a method to PasswordPolicyProvider to return a
>                  description of the
>                  policy for the admin console tooltips.
>
>                  On 25 April 2016 at 18:36, Roelof Naude
>         <roelof.naude at gmail.com <mailto:roelof.naude at gmail.com>
>                  <mailto:roelof.naude at gmail.com
>         <mailto:roelof.naude at gmail.com>>
>                  <mailto:roelof.naude at gmail.com
>         <mailto:roelof.naude at gmail.com> <mailto:roelof.naude at gmail.com
>         <mailto:roelof.naude at gmail.com>>>>
>                  wrote:
>
>                       thank you all for the quick response.
>
>                       do you guys have a basic idea on how to approach
>         the policy
>                  spi? we
>                       are more than willing to help out to get it done.
>
>                       maintaining a fork is maybe an option to resolve the
>                  immediate need,
>                       but would prefer to keep things upstream as much
>         as possible.
>
>                       On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen
>                       <sthorger at redhat.com <mailto:sthorger at redhat.com>
>         <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>
>                  <mailto:sthorger at redhat.com
>         <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>         <mailto:sthorger at redhat.com>>>> wrote:
>
>                           We an to introduce a password policy spi soon,
>         but for now
>                           you're stuck with the built-in policies.
>
>                           On 25 Apr 2016 16:43, "Bruno Oliveira"
>                  <bruno at abstractj.org <mailto:bruno at abstractj.org>
>         <mailto:bruno at abstractj.org <mailto:bruno at abstractj.org>>
>                           <mailto:bruno at abstractj.org
>         <mailto:bruno at abstractj.org>
>
>                  <mailto:bruno at abstractj.org
>         <mailto:bruno at abstractj.org>>>> wrote:
>
>                               I believe we don't have an SPI for this,
>         yet. See:
>         https://issues.jboss.org/browse/KEYCLOAK-2824.
>
>                               IMO, Argon2 is completely new and aside
>         from the
>                  bindings,
>                               we don't have
>                               a Java implementation, yet for this. I'm
>         not sure
>                  if is a
>                               good idea to
>                               introduce C to the codebase, but totally
>         doable to
>                  have an
>                               SPI for
>                               policies.
>
>                               On 2016-04-25, Roelof Naude wrote:
>                                > hi,
>                                >
>                                > a client has requested the use of the
>         argon2 [1, 2]
>                               password hashing
>                                > scheme. this can easily be added as an
>         external
>                  provider.
>                               we do however
>                                > require custom password policies, e.g.
>         memory /
>                               parallelism cost as well as
>                                > salt length. AFAIK there is no way to
>         provide policy
>                               extensions using a
>                                > provider interface?
>                                >
>                                > would argon2 be a worthwhile contribution?
>                                >
>                                > regards
>                                > roelof.
>                                >
>                                > [1]
>         https://github.com/P-H-C/phc-winner-argon2
>                                > [2] https://github.com/phxql/argon2-jvm
>
>                                >
>         _______________________________________________
>                                > keycloak-dev mailing list
>                                > keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>                  <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>>
>                               <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>                  <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>>>
>                                >
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>                               --
>
>                               abstractj
>                               PGP: 0x84DC9914
>
>           _______________________________________________
>                               keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>         <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>>
>                               <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>                  <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>>>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>

From roelof.naude at gmail.com  Fri Apr 29 09:44:51 2016
From: roelof.naude at gmail.com (Roelof Naude)
Date: Fri, 29 Apr 2016 15:44:51 +0200
Subject: [keycloak-dev] argon2 password hashing
In-Reply-To: <5723580D.20700@gmail.com>
References: <CAJuWG3=fYNxWqutaO1KntjQXnRTKfaOV6nfJEkdV3Leq--gbcg@mail.gmail.com>
	<20160425144249.GB29202@abstractj.org>
	<CAJgngAc+uBR2yujh_eeA=Mu_u61GMQw1qBcRDG6-nZvzyG34Vw@mail.gmail.com>
	<CAJuWG3m3M7iQo49gsfLc8gU-9B16LbGX1Ov+Bv5LhgB0h5GW-A@mail.gmail.com>
	<CAJgngAcm0hKRVpwzhEr_DVzN+BZQ-OAWSOAYKCBaCFEmS2L8DA@mail.gmail.com>
	<5722121C.3030107@gmail.com>
	<CAJgngAeasPJWDsp1rUsSMReZE=tcQm_X_rJJc6bNgKUsGYY47g@mail.gmail.com>
	<572311B5.30504@gmail.com>
	<CAJgngAdmn39t3eG7jjkQCXJ6FBwUq6PP=rLUvfMqNF9gJG99xw@mail.gmail.com>
	<5723580D.20700@gmail.com>
Message-ID: <CAJuWG3=v3h6gy4OxhsWs3eT5GQAcHcUppit_Xrh6kO=OzPzMNQ@mail.gmail.com>

nevermind. forgot to add the PasswordPolicySpi to the services file...

On Fri, Apr 29, 2016 at 2:48 PM, Roelof Naude <roelof.naude at gmail.com>
wrote:

> thank you, that helped.
>
> got the first round of changes done. some test cases are now failing.
> this is due to PasswordPolicy loading the PasswordPolicyProvider
> implementations. looks like the KeycloakSessionFactory::init was not
> called. factoriesMap is null.
>
> probably due to more setup / config needed. had a look at some of the
> provider tests (CustomIdentityProvider) but did not spot anything specific.
>
> do you have any hints?
>
> On 04/29/2016 11:10 AM, Stian Thorgersen wrote:
> > Pass in PasswordPolicy then. PasswordPolicy can store the config in the
> > correct format. getInt(String provider) would parse string and store as
> > an int in a map.
> >
> > This can be improved later, we're currently having a separate discussion
> > about adding something like this. Ideally password policies would also
> > support more advanced configuration like authenticators, mappers, etc
> > already do. That on the other side is more work. If you want to do
> > something like what they do that would be great though.
> >
> > On 29 April 2016 at 09:48, Roelof Naude <roelof.naude at gmail.com
> > <mailto:roelof.naude at gmail.com>> wrote:
> >
> >     hi,
> >
> >     adding the config to the verify / validate method makes no sense.
> >     take for instance HashIterations. it needs to keep the config for
> >     later when the password encode takes place. PasswordPolicy::validate
> >     is called after construction of the policies...at a time when the
> >     configuration has been parsed already. re-parsing the config for
> >     every validate can be expensive.
> >
> >     PasswordPolicyProvider implementations will most likely not access
> >     external resources. granted, one cannot foresee all future usage
> >     patterns either.
> >
> >     On 04/29/2016 07:58 AM, Stian Thorgersen wrote:
> >
> >         Simplest option is to simply add the config to the verify method.
> >
> >         We have some other SPIs that have more than one instance of a
> given
> >         provider per-realm, but as you say they're not associated with
> the
> >         session. This could cause them not to be closed, or to have
> multiple
> >         instances with same config created per-session.
> >
> >         On 28 April 2016 at 15:37, Roelof Naude <roelof.naude at gmail.com
> >         <mailto:roelof.naude at gmail.com>
> >         <mailto:roelof.naude at gmail.com <mailto:roelof.naude at gmail.com>>>
> >         wrote:
> >
> >              thank you. have made some headway with this.
> >
> >              there is a slight issue though. Providers are cached and
> >         thus mostly
> >              stateless.
> >
> >              password policies on the other hand are constructed
> >         on-demand and
> >              may contain configuration. this configuration can be
> different
> >              between various realms, e.g. HashIterations could be 20 for
> >         realm1
> >              and 200 for realm2.
> >
> >              the current provider loading mechanisms caches both the
> >         factory and
> >              provider instances.
> >
> >              1. is there a session instance per realm? if so, then there
> >         is no issue
> >              2. if not, how do you propose creating policy instances per
> >         realm?
> >
> >              PasswordPolicyFactory could expose an extra method,
> >         create(String
> >              arg), but the provider loading mechanism will ignore it.
> >         one could
> >              add specific knowledge of that method, but that feels wrong.
> >
> >              another option would be to teach KeycloakSession to return a
> >              ProviderFactory instance. PasswordPolicy could call this
> >         method to
> >              create PasswordPolicyProvider instances on-demand. this
> >         method would
> >              delegate to the underlying KeycloakSessonFactory to lookup
> the
> >              appropriate factory.
> >
> >              this last option could work. would prefer to clear it with
> >         you guys
> >              first though.
> >
> >              On 04/28/2016 07:51 AM, Stian Thorgersen wrote:
> >
> >                  First thing would be to create PasswordPolicySPI,
> >                  PasswordPolicyProviderFactory
> >                  and PasswordPolicyProvider. PasswordPolicyProvider
> >         should have same
> >                  methods as Policy. You'd then have to extract all
> >         built-in providers
> >                  from PasswordPolicy into PasswordPolicyProvider
> >         implementations,
> >                  this
> >                  should be relatively straightforward as they are
> >         already "id" ->
> >                  implementation, just means you retrieve it with
> >         KeycloakSession
> >                  rather
> >                  than hard-coded in PasswordPolicy. PasswordPolicy
> >         should then be
> >                  change
> >                  to use KeycloakSession to retrieve
> >         PasswordPolicyProvider instead of
> >                  hard-coded Policy implementations.
> >
> >                  Next step would be admin console integration. At the
> >         moment the
> >                  list of
> >                  policies is hard-coded it would need to get the list of
> >         policies
> >                  from
> >                  server-info instead. There are other bits that use
> >         server-info
> >                  to list
> >                  providers already so take a look at that. You would
> >         probably
> >                  also need
> >                  to add a method to PasswordPolicyProvider to return a
> >                  description of the
> >                  policy for the admin console tooltips.
> >
> >                  On 25 April 2016 at 18:36, Roelof Naude
> >         <roelof.naude at gmail.com <mailto:roelof.naude at gmail.com>
> >                  <mailto:roelof.naude at gmail.com
> >         <mailto:roelof.naude at gmail.com>>
> >                  <mailto:roelof.naude at gmail.com
> >         <mailto:roelof.naude at gmail.com> <mailto:roelof.naude at gmail.com
> >         <mailto:roelof.naude at gmail.com>>>>
> >                  wrote:
> >
> >                       thank you all for the quick response.
> >
> >                       do you guys have a basic idea on how to approach
> >         the policy
> >                  spi? we
> >                       are more than willing to help out to get it done.
> >
> >                       maintaining a fork is maybe an option to resolve
> the
> >                  immediate need,
> >                       but would prefer to keep things upstream as much
> >         as possible.
> >
> >                       On Mon, Apr 25, 2016 at 5:30 PM, Stian Thorgersen
> >                       <sthorger at redhat.com <mailto:sthorger at redhat.com>
> >         <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>
> >                  <mailto:sthorger at redhat.com
> >         <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
> >         <mailto:sthorger at redhat.com>>>> wrote:
> >
> >                           We an to introduce a password policy spi soon,
> >         but for now
> >                           you're stuck with the built-in policies.
> >
> >                           On 25 Apr 2016 16:43, "Bruno Oliveira"
> >                  <bruno at abstractj.org <mailto:bruno at abstractj.org>
> >         <mailto:bruno at abstractj.org <mailto:bruno at abstractj.org>>
> >                           <mailto:bruno at abstractj.org
> >         <mailto:bruno at abstractj.org>
> >
> >                  <mailto:bruno at abstractj.org
> >         <mailto:bruno at abstractj.org>>>> wrote:
> >
> >                               I believe we don't have an SPI for this,
> >         yet. See:
> >         https://issues.jboss.org/browse/KEYCLOAK-2824.
> >
> >                               IMO, Argon2 is completely new and aside
> >         from the
> >                  bindings,
> >                               we don't have
> >                               a Java implementation, yet for this. I'm
> >         not sure
> >                  if is a
> >                               good idea to
> >                               introduce C to the codebase, but totally
> >         doable to
> >                  have an
> >                               SPI for
> >                               policies.
> >
> >                               On 2016-04-25, Roelof Naude wrote:
> >                                > hi,
> >                                >
> >                                > a client has requested the use of the
> >         argon2 [1, 2]
> >                               password hashing
> >                                > scheme. this can easily be added as an
> >         external
> >                  provider.
> >                               we do however
> >                                > require custom password policies, e.g.
> >         memory /
> >                               parallelism cost as well as
> >                                > salt length. AFAIK there is no way to
> >         provide policy
> >                               extensions using a
> >                                > provider interface?
> >                                >
> >                                > would argon2 be a worthwhile
> contribution?
> >                                >
> >                                > regards
> >                                > roelof.
> >                                >
> >                                > [1]
> >         https://github.com/P-H-C/phc-winner-argon2
> >                                > [2] https://github.com/phxql/argon2-jvm
> >
> >                                >
> >         _______________________________________________
> >                                > keycloak-dev mailing list
> >                                > keycloak-dev at lists.jboss.org
> >         <mailto:keycloak-dev at lists.jboss.org>
> >                  <mailto:keycloak-dev at lists.jboss.org
> >         <mailto:keycloak-dev at lists.jboss.org>>
> >                               <mailto:keycloak-dev at lists.jboss.org
> >         <mailto:keycloak-dev at lists.jboss.org>
> >                  <mailto:keycloak-dev at lists.jboss.org
> >         <mailto:keycloak-dev at lists.jboss.org>>>
> >                                >
> >         https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >                               --
> >
> >                               abstractj
> >                               PGP: 0x84DC9914
> >
> >           _______________________________________________
> >                               keycloak-dev mailing list
> >         keycloak-dev at lists.jboss.org
> >         <mailto:keycloak-dev at lists.jboss.org>
> >         <mailto:keycloak-dev at lists.jboss.org
> >         <mailto:keycloak-dev at lists.jboss.org>>
> >                               <mailto:keycloak-dev at lists.jboss.org
> >         <mailto:keycloak-dev at lists.jboss.org>
> >                  <mailto:keycloak-dev at lists.jboss.org
> >         <mailto:keycloak-dev at lists.jboss.org>>>
> >         https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/a60c7074/attachment-0001.html 

From bburke at redhat.com  Fri Apr 29 10:07:45 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 29 Apr 2016 10:07:45 -0400
Subject: [keycloak-dev] max entry default for realm cache?
In-Reply-To: <CAOjtoUOWfFbnDgEvxMAP-pMdLrp+2RV1t4yG1CqZWUBe+xda_Q@mail.gmail.com>
References: <25121b84-9f8c-8603-8d3d-ce54beb159ee@redhat.com>
	<CAOjtoUOWfFbnDgEvxMAP-pMdLrp+2RV1t4yG1CqZWUBe+xda_Q@mail.gmail.com>
Message-ID: <55c71bf2-39a9-6d4a-bbed-29302462f746@redhat.com>

sessions aren't a problem as we check for idleness.

@Stian, no there is not a problem with the current setup.  I was worried 
that realm cache was bounded and was just making sure.


On 4/28/2016 9:43 PM, Fabricio Milone wrote:
> As per the documentation on 
> http://infinispan.org/docs/8.0.x/user_guide/user_guide.html#_more_defaults 
> and keycloak standalone.xml file, I can see that none of those caches 
> have eviction enabled.
>
> I'm just wondering why is the realm cache the one you are asking for. 
> Wouldn't be more dangerous in terms of memory the sessions or users 
> cache instead?
>
>
> On 29 April 2016 at 07:44, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     What is the max entry default for realm cache? Is it unbounded? 
>     I'm looking at infinispan docs and it seems the default eviction
>     strategy is nothing.
>
>
>     -- 
>     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
>
>
>
>
> -- 
> *Fabricio Milone*
> Developer
> *
> *
> *
> Shine Consulting *
>
> 30/600 Bourke Street
>
> Melbourne VIC 3000
>
> T: 03 8488 9939
>
> M: 04 3200 4006
>
>
> www.shinetech.com <http://www.shinetech.com/>/*a*/ passion for excellence
>

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

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

From bburke at redhat.com  Fri Apr 29 10:19:28 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 29 Apr 2016 10:19:28 -0400
Subject: [keycloak-dev] Thinking about step-up authentication and token
 timeouts
In-Reply-To: <CAJgngAf5VX-+StUGCaZYH2asMori7X2g5zFVcn8SrOT=XjRCKg@mail.gmail.com>
References: <CAJgngAf5VX-+StUGCaZYH2asMori7X2g5zFVcn8SrOT=XjRCKg@mail.gmail.com>
Message-ID: <6b9e58e9-65f9-87ac-8991-f6ccab25aca8@redhat.com>

Sounds great.  I hope we don't have to implement this for SAML too ;)

On 4/29/2016 12:02 AM, Stian Thorgersen wrote:
> Clients should be able to obtain tokens with reduced scope and longer 
> or shorter expiration, then later request new tokens with increased 
> scope and different expiration. They should also be able to require 
> different levels of authentication and also require re-authentication.
>
> An application may for example:
>
> * At first only need users email - this would allow showing the name + 
> email. In this situation a long expiration access token in combination 
> with implicit flow would do. It's also not necessary to 
> re-authenticate the user and a user that has been logged-in for months 
> or even a year is fine.
>
> * When a user clicks on orders it would require the password and 
> extend scope to be able to view orders. Now you'll want to switch to 
> short expiration access tokens and authorization code grant. You'll 
> also want to make sure the user logged-in fairly recently, max 30 days 
> could be sensible.
>
> * When a user tries to purchase something the user now has to provide 
> the OTP to be able to purchase with saved credit card details. You'll 
> also want to make sure the user logged-in very recently, max a day 
> could be required. There may also be cases where you always want the 
> user to re-authenticate, for example when trying to purchase something 
> over a certain price level.
>
>
> _______________________________________________
> 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

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

From lholmqui at redhat.com  Fri Apr 29 13:09:21 2016
From: lholmqui at redhat.com (Luke Holmquist)
Date: Fri, 29 Apr 2016 13:09:21 -0400
Subject: [keycloak-dev] (no subject)
Message-ID: <CALD3Fd08EhV0m3nq_w=kzqkSP21FSk66AgmOzGYq5yv92-X=_A@mail.gmail.com>

I have a use case, that i think could be pretty common,  but i'm not
entirely sure how to setup it up.

The following is a little bit of a thought dump, so pardon me if i ramble a
little bit.


There are i think 3 components involved here:

1. a pure HTML/JS web app

2. A node.js REST  API server

3. Keycloak server


The app in this case, would not be served by the node server or the KC
server(wildfly), but with something like nginx(or even something like
'python simpleHTTPServer')

Basically the flow would be something like this[1]:

The web app, using the js adapter, authenticates against the KC server.

 Now the web app would like to call the node API server(a restricted
endpoint) to get some data

The web app probably adds the token stuff that it got from KC during it;s
login to the request to the node server

***This next part is where i'm getting a little confused, i'm aware that
code to do this might not be written yet****

I'm thinking the node server takes the token from the web app request, and
would hit an endpoint on the KC server to make sure that token is valid.

If things go ok, then node server returns the data.

I've seen the recent post on doing token introspection and abstracj was
nice enough to make that into a gist,
https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061

but this would also mean the web client access_type would need to be
confidential(which i don't think is secure for a web app) to make a service
account that the node server could use to do the token introspection.

I was thinking of maybe creating a client also for the node server, but is
it possible for 1 client to lookup/validate tokens from another client.


Perhaps i'm thinking about this all wrong too, which is very possible.

In this example there is only 1 node api server,  but there could be
multiple node/go/rust/<insert cool kid tech here> servers too



Any guidance would be appreciated and sorry for the ramble

-Luke






[1]
https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/7e67d129/attachment.html 

From lholmqui at redhat.com  Fri Apr 29 13:12:24 2016
From: lholmqui at redhat.com (Luke Holmquist)
Date: Fri, 29 Apr 2016 13:12:24 -0400
Subject: [keycloak-dev] html app, node api server and keycloak
Message-ID: <CALD3Fd2v7VnPdwaTq4+JZN9PyVJYQ+y8rAtw0ckgt+0fw84MQA@mail.gmail.com>

crap, forget the subject line

On Fri, Apr 29, 2016 at 1:09 PM, Luke Holmquist <lholmqui at redhat.com> wrote:

> I have a use case, that i think could be pretty common,  but i'm not
> entirely sure how to setup it up.
>
> The following is a little bit of a thought dump, so pardon me if i ramble
> a little bit.
>
>
> There are i think 3 components involved here:
>
> 1. a pure HTML/JS web app
>
> 2. A node.js REST  API server
>
> 3. Keycloak server
>
>
> The app in this case, would not be served by the node server or the KC
> server(wildfly), but with something like nginx(or even something like
> 'python simpleHTTPServer')
>
> Basically the flow would be something like this[1]:
>
> The web app, using the js adapter, authenticates against the KC server.
>
>  Now the web app would like to call the node API server(a restricted
> endpoint) to get some data
>
> The web app probably adds the token stuff that it got from KC during it;s
> login to the request to the node server
>
> ***This next part is where i'm getting a little confused, i'm aware that
> code to do this might not be written yet****
>
> I'm thinking the node server takes the token from the web app request, and
> would hit an endpoint on the KC server to make sure that token is valid.
>
> If things go ok, then node server returns the data.
>
> I've seen the recent post on doing token introspection and abstracj was
> nice enough to make that into a gist,
> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
>
> but this would also mean the web client access_type would need to be
> confidential(which i don't think is secure for a web app) to make a service
> account that the node server could use to do the token introspection.
>
> I was thinking of maybe creating a client also for the node server, but is
> it possible for 1 client to lookup/validate tokens from another client.
>
>
> Perhaps i'm thinking about this all wrong too, which is very possible.
>
> In this example there is only 1 node api server,  but there could be
> multiple node/go/rust/<insert cool kid tech here> servers too
>
>
>
> Any guidance would be appreciated and sorry for the ramble
>
> -Luke
>
>
>
>
>
>
> [1]
> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
>
> _______________________________________________
> 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/20160429/5b7cb88d/attachment-0001.html 

From gambol99 at gmail.com  Fri Apr 29 14:01:24 2016
From: gambol99 at gmail.com (gambol)
Date: Fri, 29 Apr 2016 19:01:24 +0100
Subject: [keycloak-dev] html app, node api server and keycloak
In-Reply-To: <CALD3Fd2v7VnPdwaTq4+JZN9PyVJYQ+y8rAtw0ckgt+0fw84MQA@mail.gmail.com>
References: <CALD3Fd2v7VnPdwaTq4+JZN9PyVJYQ+y8rAtw0ckgt+0fw84MQA@mail.gmail.com>
Message-ID: <CA+AP+fMwRH2gPUEMx-WXb0C-JRRt6+97ysWrdj06vnWTk6quLw@mail.gmail.com>

If I'm not mistaken the access type would be 'public' since you can't
secure the client secret (
http://stackoverflow.com/questions/14574846/client-authentication-on-public-client)
...

In regard to the API, there's technically no need to speak to keycloak to
verify the token, given the jwt is signed by the provider. So assuming the
library your using on the API pulls the jwt public keys from keycloak
(openid discovery URL perhaps) or has it hardcoded, you have everything you
need to verify the the token.

Rohith
crap, forget the subject line

On Fri, Apr 29, 2016 at 1:09 PM, Luke Holmquist <lholmqui at redhat.com> wrote:

> I have a use case, that i think could be pretty common,  but i'm not
> entirely sure how to setup it up.
>
> The following is a little bit of a thought dump, so pardon me if i ramble
> a little bit.
>
>
> There are i think 3 components involved here:
>
> 1. a pure HTML/JS web app
>
> 2. A node.js REST  API server
>
> 3. Keycloak server
>
>
> The app in this case, would not be served by the node server or the KC
> server(wildfly), but with something like nginx(or even something like
> 'python simpleHTTPServer')
>
> Basically the flow would be something like this[1]:
>
> The web app, using the js adapter, authenticates against the KC server.
>
>  Now the web app would like to call the node API server(a restricted
> endpoint) to get some data
>
> The web app probably adds the token stuff that it got from KC during it;s
> login to the request to the node server
>
> ***This next part is where i'm getting a little confused, i'm aware that
> code to do this might not be written yet****
>
> I'm thinking the node server takes the token from the web app request, and
> would hit an endpoint on the KC server to make sure that token is valid.
>
> If things go ok, then node server returns the data.
>
> I've seen the recent post on doing token introspection and abstracj was
> nice enough to make that into a gist,
> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
>
> but this would also mean the web client access_type would need to be
> confidential(which i don't think is secure for a web app) to make a service
> account that the node server could use to do the token introspection.
>
> I was thinking of maybe creating a client also for the node server, but is
> it possible for 1 client to lookup/validate tokens from another client.
>
>
> Perhaps i'm thinking about this all wrong too, which is very possible.
>
> In this example there is only 1 node api server,  but there could be
> multiple node/go/rust/<insert cool kid tech here> servers too
>
>
>
> Any guidance would be appreciated and sorry for the ramble
>
> -Luke
>
>
>
>
>
>
> [1]
> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/19cdbe8f/attachment.html 

From lholmqui at redhat.com  Fri Apr 29 14:03:45 2016
From: lholmqui at redhat.com (Luke Holmquist)
Date: Fri, 29 Apr 2016 14:03:45 -0400
Subject: [keycloak-dev] html app, node api server and keycloak
In-Reply-To: <CA+AP+fMwRH2gPUEMx-WXb0C-JRRt6+97ysWrdj06vnWTk6quLw@mail.gmail.com>
References: <CALD3Fd2v7VnPdwaTq4+JZN9PyVJYQ+y8rAtw0ckgt+0fw84MQA@mail.gmail.com>
	<CA+AP+fMwRH2gPUEMx-WXb0C-JRRt6+97ysWrdj06vnWTk6quLw@mail.gmail.com>
Message-ID: <CALD3Fd3wteM5+AT0s-UCWkbSQETQNpRf-Bo2LFSGs=yBrmMg-Q@mail.gmail.com>

On Fri, Apr 29, 2016 at 2:01 PM, gambol <gambol99 at gmail.com> wrote:

> If I'm not mistaken the access type would be 'public' since you can't
> secure the client secret (
> http://stackoverflow.com/questions/14574846/client-authentication-on-public-client)
> ...
>
Yeah, i think that was always the plan for the html app, possibly also with
the implicit grant flow

> In regard to the API, there's technically no need to speak to keycloak to
> verify the token, given the jwt is signed by the provider. So assuming the
> library your using on the API pulls the jwt public keys from keycloak
> (openid discovery URL perhaps) or has it hardcoded, you have everything you
> need to verify the the token.
>
> Rohith
> crap, forget the subject line
>
> On Fri, Apr 29, 2016 at 1:09 PM, Luke Holmquist <lholmqui at redhat.com>
> wrote:
>
>> I have a use case, that i think could be pretty common,  but i'm not
>> entirely sure how to setup it up.
>>
>> The following is a little bit of a thought dump, so pardon me if i ramble
>> a little bit.
>>
>>
>> There are i think 3 components involved here:
>>
>> 1. a pure HTML/JS web app
>>
>> 2. A node.js REST  API server
>>
>> 3. Keycloak server
>>
>>
>> The app in this case, would not be served by the node server or the KC
>> server(wildfly), but with something like nginx(or even something like
>> 'python simpleHTTPServer')
>>
>> Basically the flow would be something like this[1]:
>>
>> The web app, using the js adapter, authenticates against the KC server.
>>
>>  Now the web app would like to call the node API server(a restricted
>> endpoint) to get some data
>>
>> The web app probably adds the token stuff that it got from KC during it;s
>> login to the request to the node server
>>
>> ***This next part is where i'm getting a little confused, i'm aware that
>> code to do this might not be written yet****
>>
>> I'm thinking the node server takes the token from the web app request,
>> and would hit an endpoint on the KC server to make sure that token is
>> valid.
>>
>> If things go ok, then node server returns the data.
>>
>> I've seen the recent post on doing token introspection and abstracj was
>> nice enough to make that into a gist,
>> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
>>
>> but this would also mean the web client access_type would need to be
>> confidential(which i don't think is secure for a web app) to make a service
>> account that the node server could use to do the token introspection.
>>
>> I was thinking of maybe creating a client also for the node server, but
>> is it possible for 1 client to lookup/validate tokens from another client.
>>
>>
>> Perhaps i'm thinking about this all wrong too, which is very possible.
>>
>> In this example there is only 1 node api server,  but there could be
>> multiple node/go/rust/<insert cool kid tech here> servers too
>>
>>
>>
>> Any guidance would be appreciated and sorry for the ramble
>>
>> -Luke
>>
>>
>>
>>
>>
>>
>> [1]
>> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/34983a2b/attachment.html 

From lholmqui at redhat.com  Fri Apr 29 14:18:23 2016
From: lholmqui at redhat.com (Luke Holmquist)
Date: Fri, 29 Apr 2016 14:18:23 -0400
Subject: [keycloak-dev] html app, node api server and keycloak
In-Reply-To: <CALD3Fd3wteM5+AT0s-UCWkbSQETQNpRf-Bo2LFSGs=yBrmMg-Q@mail.gmail.com>
References: <CALD3Fd2v7VnPdwaTq4+JZN9PyVJYQ+y8rAtw0ckgt+0fw84MQA@mail.gmail.com>
	<CA+AP+fMwRH2gPUEMx-WXb0C-JRRt6+97ysWrdj06vnWTk6quLw@mail.gmail.com>
	<CALD3Fd3wteM5+AT0s-UCWkbSQETQNpRf-Bo2LFSGs=yBrmMg-Q@mail.gmail.com>
Message-ID: <CALD3Fd39RxcNTZ3bX=NF2UcCd9qRBxa9VAj0gRW1BFMkArGEBA@mail.gmail.com>

On Fri, Apr 29, 2016 at 2:03 PM, Luke Holmquist <lholmqui at redhat.com> wrote:

>
>
> On Fri, Apr 29, 2016 at 2:01 PM, gambol <gambol99 at gmail.com> wrote:
>
>> If I'm not mistaken the access type would be 'public' since you can't
>> secure the client secret (
>> http://stackoverflow.com/questions/14574846/client-authentication-on-public-client)
>> ...
>>
> Yeah, i think that was always the plan for the html app, possibly also
> with the implicit grant flow
>
>> In regard to the API, there's technically no need to speak to keycloak to
>> verify the token, given the jwt is signed by the provider. So assuming the
>> library your using on the API pulls the jwt public keys from keycloak
>> (openid discovery URL perhaps) or has it hardcoded, you have everything you
>> need to verify the the token.
>>
> It looks like though with the public client, there is no access to the
"credentials" tab that would allow me to switch on sign jwt's  or are you
talking about something completely different?

> Rohith
>> crap, forget the subject line
>>
>> On Fri, Apr 29, 2016 at 1:09 PM, Luke Holmquist <lholmqui at redhat.com>
>> wrote:
>>
>>> I have a use case, that i think could be pretty common,  but i'm not
>>> entirely sure how to setup it up.
>>>
>>> The following is a little bit of a thought dump, so pardon me if i
>>> ramble a little bit.
>>>
>>>
>>> There are i think 3 components involved here:
>>>
>>> 1. a pure HTML/JS web app
>>>
>>> 2. A node.js REST  API server
>>>
>>> 3. Keycloak server
>>>
>>>
>>> The app in this case, would not be served by the node server or the KC
>>> server(wildfly), but with something like nginx(or even something like
>>> 'python simpleHTTPServer')
>>>
>>> Basically the flow would be something like this[1]:
>>>
>>> The web app, using the js adapter, authenticates against the KC server.
>>>
>>>  Now the web app would like to call the node API server(a restricted
>>> endpoint) to get some data
>>>
>>> The web app probably adds the token stuff that it got from KC during
>>> it;s login to the request to the node server
>>>
>>> ***This next part is where i'm getting a little confused, i'm aware that
>>> code to do this might not be written yet****
>>>
>>> I'm thinking the node server takes the token from the web app request,
>>> and would hit an endpoint on the KC server to make sure that token is
>>> valid.
>>>
>>> If things go ok, then node server returns the data.
>>>
>>> I've seen the recent post on doing token introspection and abstracj was
>>> nice enough to make that into a gist,
>>> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
>>>
>>> but this would also mean the web client access_type would need to be
>>> confidential(which i don't think is secure for a web app) to make a service
>>> account that the node server could use to do the token introspection.
>>>
>>> I was thinking of maybe creating a client also for the node server, but
>>> is it possible for 1 client to lookup/validate tokens from another client.
>>>
>>>
>>> Perhaps i'm thinking about this all wrong too, which is very possible.
>>>
>>> In this example there is only 1 node api server,  but there could be
>>> multiple node/go/rust/<insert cool kid tech here> servers too
>>>
>>>
>>>
>>> Any guidance would be appreciated and sorry for the ramble
>>>
>>> -Luke
>>>
>>>
>>>
>>>
>>>
>>>
>>> [1]
>>> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160429/39d527a4/attachment-0001.html 

From sblanc at redhat.com  Fri Apr 29 14:23:28 2016
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 29 Apr 2016 20:23:28 +0200
Subject: [keycloak-dev] (no subject)
In-Reply-To: <CALD3Fd08EhV0m3nq_w=kzqkSP21FSk66AgmOzGYq5yv92-X=_A@mail.gmail.com>
References: <CALD3Fd08EhV0m3nq_w=kzqkSP21FSk66AgmOzGYq5yv92-X=_A@mail.gmail.com>
Message-ID: <CAMZCGg-51TwO9bBQ7Ti430RSfJ+nd4amxyotzOJ6fET=ZPQnHA@mail.gmail.com>

Hi Luke !


I might be wrong but I think I have the exact demo working of what you
describe :

1. the standalone webapp client :
https://github.com/sebastienblanc/devoxxfr/tree/master/angular-client , you
can run it with "grunt serve"
2. the nodejs service :
https://github.com/sebastienblanc/devoxxfr/tree/master/nodejs-service , run
it with "npm start"
3. external keycloak server running


I did not need to define any confidential client, the trick is to use
"bearer-only" for the nodejs service, take a look at my sample realm :
https://github.com/sebastienblanc/devoxxfr/blob/master/devoxxrealm.json

And sorry if I was completly aside what you meant.

Sebi


On Fri, Apr 29, 2016 at 7:09 PM, Luke Holmquist <lholmqui at redhat.com> wrote:

> I have a use case, that i think could be pretty common,  but i'm not
> entirely sure how to setup it up.
>
> The following is a little bit of a thought dump, so pardon me if i ramble
> a little bit.
>
>
> There are i think 3 components involved here:
>
> 1. a pure HTML/JS web app
>
> 2. A node.js REST  API server
>
> 3. Keycloak server
>
>
> The app in this case, would not be served by the node server or the KC
> server(wildfly), but with something like nginx(or even something like
> 'python simpleHTTPServer')
>
> Basically the flow would be something like this[1]:
>
> The web app, using the js adapter, authenticates against the KC server.
>
>  Now the web app would like to call the node API server(a restricted
> endpoint) to get some data
>
> The web app probably adds the token stuff that it got from KC during it;s
> login to the request to the node server
>
> ***This next part is where i'm getting a little confused, i'm aware that
> code to do this might not be written yet****
>
> I'm thinking the node server takes the token from the web app request, and
> would hit an endpoint on the KC server to make sure that token is valid.
>
> If things go ok, then node server returns the data.
>
> I've seen the recent post on doing token introspection and abstracj was
> nice enough to make that into a gist,
> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
>
> but this would also mean the web client access_type would need to be
> confidential(which i don't think is secure for a web app) to make a service
> account that the node server could use to do the token introspection.
>
> I was thinking of maybe creating a client also for the node server, but is
> it possible for 1 client to lookup/validate tokens from another client.
>
>
> Perhaps i'm thinking about this all wrong too, which is very possible.
>
> In this example there is only 1 node api server,  but there could be
> multiple node/go/rust/<insert cool kid tech here> servers too
>
>
>
> Any guidance would be appreciated and sorry for the ramble
>
> -Luke
>
>
>
>
>
>
> [1]
> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
>
> _______________________________________________
> 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/20160429/f9fb94c0/attachment.html 

From lholmqui at redhat.com  Fri Apr 29 14:44:46 2016
From: lholmqui at redhat.com (Luke Holmquist)
Date: Fri, 29 Apr 2016 14:44:46 -0400
Subject: [keycloak-dev] (no subject)
In-Reply-To: <CAMZCGg-51TwO9bBQ7Ti430RSfJ+nd4amxyotzOJ6fET=ZPQnHA@mail.gmail.com>
References: <CALD3Fd08EhV0m3nq_w=kzqkSP21FSk66AgmOzGYq5yv92-X=_A@mail.gmail.com>
	<CAMZCGg-51TwO9bBQ7Ti430RSfJ+nd4amxyotzOJ6fET=ZPQnHA@mail.gmail.com>
Message-ID: <CALD3Fd370uR3fQ6HWc38fwv=wuwvJqwfCBoEXs4PQG3SfxB88A@mail.gmail.com>

On Fri, Apr 29, 2016 at 2:23 PM, Sebastien Blanc <sblanc at redhat.com> wrote:

> Hi Luke !
>
>
> I might be wrong but I think I have the exact demo working of what you
> describe :
>
> 1. the standalone webapp client :
> https://github.com/sebastienblanc/devoxxfr/tree/master/angular-client ,
> you can run it with "grunt serve"
> 2. the nodejs service :
> https://github.com/sebastienblanc/devoxxfr/tree/master/nodejs-service ,
> run it with "npm start"
> 3. external keycloak server running
>
>
> I did not need to define any confidential client, the trick is to use
> "bearer-only" for the nodejs service, take a look at my sample realm :
> https://github.com/sebastienblanc/devoxxfr/blob/master/devoxxrealm.json
>
> i also see another realm file inside the nodejs-service directory,  is
that for something else.  looks like it would be if you were "logging in"
to the node server


> And sorry if I was completly aside what you meant.
>
> Sebi
>
>
> On Fri, Apr 29, 2016 at 7:09 PM, Luke Holmquist <lholmqui at redhat.com>
> wrote:
>
>> I have a use case, that i think could be pretty common,  but i'm not
>> entirely sure how to setup it up.
>>
>> The following is a little bit of a thought dump, so pardon me if i ramble
>> a little bit.
>>
>>
>> There are i think 3 components involved here:
>>
>> 1. a pure HTML/JS web app
>>
>> 2. A node.js REST  API server
>>
>> 3. Keycloak server
>>
>>
>> The app in this case, would not be served by the node server or the KC
>> server(wildfly), but with something like nginx(or even something like
>> 'python simpleHTTPServer')
>>
>> Basically the flow would be something like this[1]:
>>
>> The web app, using the js adapter, authenticates against the KC server.
>>
>>  Now the web app would like to call the node API server(a restricted
>> endpoint) to get some data
>>
>> The web app probably adds the token stuff that it got from KC during it;s
>> login to the request to the node server
>>
>> ***This next part is where i'm getting a little confused, i'm aware that
>> code to do this might not be written yet****
>>
>> I'm thinking the node server takes the token from the web app request,
>> and would hit an endpoint on the KC server to make sure that token is
>> valid.
>>
>> If things go ok, then node server returns the data.
>>
>> I've seen the recent post on doing token introspection and abstracj was
>> nice enough to make that into a gist,
>> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
>>
>> but this would also mean the web client access_type would need to be
>> confidential(which i don't think is secure for a web app) to make a service
>> account that the node server could use to do the token introspection.
>>
>> I was thinking of maybe creating a client also for the node server, but
>> is it possible for 1 client to lookup/validate tokens from another client.
>>
>>
>> Perhaps i'm thinking about this all wrong too, which is very possible.
>>
>> In this example there is only 1 node api server,  but there could be
>> multiple node/go/rust/<insert cool kid tech here> servers too
>>
>>
>>
>> Any guidance would be appreciated and sorry for the ramble
>>
>> -Luke
>>
>>
>>
>>
>>
>>
>> [1]
>> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
>>
>> _______________________________________________
>> 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/20160429/3354386f/attachment.html 

From bruno at abstractj.org  Fri Apr 29 15:57:20 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 29 Apr 2016 16:57:20 -0300
Subject: [keycloak-dev] (no subject)
In-Reply-To: <CALD3Fd370uR3fQ6HWc38fwv=wuwvJqwfCBoEXs4PQG3SfxB88A@mail.gmail.com>
References: <CALD3Fd08EhV0m3nq_w=kzqkSP21FSk66AgmOzGYq5yv92-X=_A@mail.gmail.com>
	<CAMZCGg-51TwO9bBQ7Ti430RSfJ+nd4amxyotzOJ6fET=ZPQnHA@mail.gmail.com>
	<CALD3Fd370uR3fQ6HWc38fwv=wuwvJqwfCBoEXs4PQG3SfxB88A@mail.gmail.com>
Message-ID: <20160429195720.GA13464@abstractj.org>

Luke, I believe this is what you're trying to achieve:


     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+
Taken from: https://tools.ietf.org/html/rfc6750

If yes, I believe Sebi's examples cover your scenario.
(I didn't have the chance to try Sebi's example)


On 2016-04-29, Luke Holmquist wrote:
> On Fri, Apr 29, 2016 at 2:23 PM, Sebastien Blanc <sblanc at redhat.com> wrote:
>
> > Hi Luke !
> >
> >
> > I might be wrong but I think I have the exact demo working of what you
> > describe :
> >
> > 1. the standalone webapp client :
> > https://github.com/sebastienblanc/devoxxfr/tree/master/angular-client ,
> > you can run it with "grunt serve"
> > 2. the nodejs service :
> > https://github.com/sebastienblanc/devoxxfr/tree/master/nodejs-service ,
> > run it with "npm start"
> > 3. external keycloak server running
> >
> >
> > I did not need to define any confidential client, the trick is to use
> > "bearer-only" for the nodejs service, take a look at my sample realm :
> > https://github.com/sebastienblanc/devoxxfr/blob/master/devoxxrealm.json
> >
> > i also see another realm file inside the nodejs-service directory,  is
> that for something else.  looks like it would be if you were "logging in"
> to the node server
>
>
> > And sorry if I was completly aside what you meant.
> >
> > Sebi
> >
> >
> > On Fri, Apr 29, 2016 at 7:09 PM, Luke Holmquist <lholmqui at redhat.com>
> > wrote:
> >
> >> I have a use case, that i think could be pretty common,  but i'm not
> >> entirely sure how to setup it up.
> >>
> >> The following is a little bit of a thought dump, so pardon me if i ramble
> >> a little bit.
> >>
> >>
> >> There are i think 3 components involved here:
> >>
> >> 1. a pure HTML/JS web app
> >>
> >> 2. A node.js REST  API server
> >>
> >> 3. Keycloak server
> >>
> >>
> >> The app in this case, would not be served by the node server or the KC
> >> server(wildfly), but with something like nginx(or even something like
> >> 'python simpleHTTPServer')
> >>
> >> Basically the flow would be something like this[1]:
> >>
> >> The web app, using the js adapter, authenticates against the KC server.
> >>
> >>  Now the web app would like to call the node API server(a restricted
> >> endpoint) to get some data
> >>
> >> The web app probably adds the token stuff that it got from KC during it;s
> >> login to the request to the node server
> >>
> >> ***This next part is where i'm getting a little confused, i'm aware that
> >> code to do this might not be written yet****
> >>
> >> I'm thinking the node server takes the token from the web app request,
> >> and would hit an endpoint on the KC server to make sure that token is
> >> valid.
> >>
> >> If things go ok, then node server returns the data.
> >>
> >> I've seen the recent post on doing token introspection and abstracj was
> >> nice enough to make that into a gist,
> >> https://gist.github.com/abstractj/4cd2231a472069d8b6f63b4008c74061
> >>
> >> but this would also mean the web client access_type would need to be
> >> confidential(which i don't think is secure for a web app) to make a service
> >> account that the node server could use to do the token introspection.
> >>
> >> I was thinking of maybe creating a client also for the node server, but
> >> is it possible for 1 client to lookup/validate tokens from another client.
> >>
> >>
> >> Perhaps i'm thinking about this all wrong too, which is very possible.
> >>
> >> In this example there is only 1 node api server,  but there could be
> >> multiple node/go/rust/<insert cool kid tech here> servers too
> >>
> >>
> >>
> >> Any guidance would be appreciated and sorry for the ramble
> >>
> >> -Luke
> >>
> >>
> >>
> >>
> >>
> >>
> >> [1]
> >> https://docs.google.com/drawings/d/1BngijxAV2j0rjz18P0XcXeY9CClCg1mwQhROYQ2iWtU/edit
> >>
> >> _______________________________________________
> >> 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


--

abstractj
PGP: 0x84DC9914