From gerbermichi at me.com  Thu Jan  1 08:26:12 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Thu, 01 Jan 2015 14:26:12 +0100
Subject: [keycloak-dev] reset-password-email web service proposal for
	modification
Message-ID: <64C45159-330E-46AA-9444-BFE8C8CEAFDA@me.com>

Hi

The reset-password-email rest web service sends an email to the user with the following content:
Someone just requested to change your Keycloak account's password. If this was you, click on the link below to set a new password: 
http://localhost:8081/auth/realms/master/login-actions/password-reset?code=sI_NFQE1iMBoWhBnuoN674eHyBh5IMi_R2QbQ41X5iY.b1cc4d2a-d02d-4819-8156-17b2dd5e034d <http://localhost:8081/auth/realms/master/login-actions/password-reset?code=sI_NFQE1iMBoWhBnuoN674eHyBh5IMi_R2QbQ41X5iY.b1cc4d2a-d02d-4819-8156-17b2dd5e034d>

The link above navigates to a form where the user has to enter his username or email address. After that he retrieves an other email with the following content:
Someone just requested to change your Keycloak account's password. If this was you, click on the link below to set a new password:
http://localhost:8081/auth/realms/master/login-actions/password-reset?key=Rhs73F1fSOznR-Z3sliNXSVKNBQeKyY8-4qlXqA5buI.b1cc4d2a-d02d-4819-8156-17b2dd5e034d <http://localhost:8081/auth/realms/master/login-actions/password-reset?key=Rhs73F1fSOznR-Z3sliNXSVKNBQeKyY8-4qlXqA5buI.b1cc4d2a-d02d-4819-8156-17b2dd5e034d>

The user can than finally change his password and gets redirected to the keycloak account page.

I think this process is a bit complicated. Isn?t it possible to send just one email? And it would be nice to pass a redirect URI to the web service.
I implemented the described changes to show you what I mean: 
https://github.com/gerbermichi/keycloak/commit/1a892b70b1e788dfc5565d29f1eeeab80109d070 <https://github.com/gerbermichi/keycloak/commit/1a892b70b1e788dfc5565d29f1eeeab80109d070>

Best
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150101/c3a2758d/attachment-0001.html 

From stian at redhat.com  Fri Jan  2 02:34:47 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 2 Jan 2015 02:34:47 -0500 (EST)
Subject: [keycloak-dev] Access original session
In-Reply-To: <54A2BAE4.2050007@gmail.com>
References: <549FD512.9020705@gmail.com>
	<349569894.2249184.1419943101421.JavaMail.zimbra@redhat.com>
	<54A29E59.7030008@gmail.com>
	<1057182580.2251047.1419944384069.JavaMail.zimbra@redhat.com>
	<54A2BAE4.2050007@gmail.com>
Message-ID: <792210726.2563607.1420184087778.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Christian Beikov" <christian.beikov at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 30 December, 2014 3:47:00 PM
> Subject: Re: [keycloak-dev] Access original session
> 
> I am using the following versions:
> 
>   * Keycloak 1.0.4.Final
>   * Wildfly 8.1.0.Final
> 
> Also it doesn't respect the cookie settings of the web.xml. I tried to
> configure a different name for the cookie just to test it, but it didn't
> change. When navigating to "/whatever.xhtml" I suddenly get the
> configured cookie set.
> It seems as if the Keycloak adapters wrap the HttpServletRequest to
> expose a different session map when working with secured resources.
> Which demo are you talking about? I would love to try it out so that I
> can confirm if it has something to do with my setup or Keycloak.

Keycloak should just be using the underlying http session and not do anything special to it. Do you have the same problem with HTTP basic?

The demo I'm referring to is the one that is bundled with the download, it's in examples/preconfigured-demo

> 
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 30.12.2014 um 13:59 schrieb Stian Thorgersen:
> >
> > ----- Original Message -----
> >> From: "Christian Beikov" <christian.beikov at gmail.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 30 December, 2014 1:45:13 PM
> >> Subject: Re: [keycloak-dev] Access original session
> >>
> >> Seems like my question wasn't clear enough.
> >>
> >> I have the following config in my web.xml
> >>
> >>       <security-constraint>
> >>           <web-resource-collection>
> >> <web-resource-name>Protected</web-resource-name>
> >>               <url-pattern>/protected/*</url-pattern>
> >>           </web-resource-collection>
> >>           <auth-constraint>
> >>               <role-name>user</role-name>
> >>           </auth-constraint>
> >>       </security-constraint>
> >>
> >>       <login-config>
> >>           <auth-method>KEYCLOAK</auth-method>
> >>           <realm-name>portfolio-webapp</realm-name>
> >>       </login-config>
> >>
> >>       <security-role>
> >>           <role-name>user</role-name>
> >>       </security-role>
> >>
> >> Now when I navigate to e.g. "/protected/index.xhtml" I get redirected to
> >> the Keycloak login. Unfortunately, the cookie which is set by the
> >> Keycloak adapters after a succesful login, has the path "/protected"
> >> set. When I navigate to "/whatever.xhtml" I obviously have no access to
> >> the cookie since the browser doesn't send it.
> >>
> >> How am I supposed to access the logged in user outside of the protected
> >> area?
> >>
> >> The session cookie (assuming you're talking about JSESSIONID) should be
> >> set
> >> to the context-path of your WAR not a specific protected resource.
> >>
> >> Unfortunately I am experiencing that it is set to a different path.
> > Strange. I've just tried with our demo, which has a similar
> > security-constraint to yours, and it sets it to the context-path of the
> > WAR as expected.
> >
> > Keycloak doesn't set this cookie itself, that's sorted by the JEE
> > container. Which Keycloak version and JEE server are you using?
> >
> >> Is your protected resources in the same WAR as the unprotected resources?
> >>
> >> Yes, it's all in the same WAR.
> >>
> >> Mit freundlichen Gr??en,
> >> ------------------------------------------------------------------------
> >> *Christian Beikov*
> >> Am 30.12.2014 um 13:38 schrieb Stian Thorgersen:
> >>> The session cookie (assuming you're talking about JSESSIONID) should be
> >>> set
> >>> to the context-path of your WAR not a specific protected resource. Is
> >>> your
> >>> protected resources in the same WAR as the unprotected resources?
> >>>
> >>> ----- Original Message -----
> >>>> From: "Christian Beikov" <christian.beikov at gmail.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Sunday, 28 December, 2014 11:01:54 AM
> >>>> Subject: [keycloak-dev] Access original session
> >>>>
> >>>> Hello there!"
> >>>>
> >>>> I have an application that has protected resources on the pattern
> >>>> "/protected/*" and I receive a session cookie for the path "/protected",
> >>>> which makes sense. Now my problem is, that I want the path of the cookie
> >>>> to
> >>>> be "/" so I can access the user information even outside of the
> >>>> protected
> >>>> resources.
> >>>> Since I think this might introduce some problems, the only other way to
> >>>> realize that I could think of is, to get access to the underlying
> >>>> servlet
> >>>> session. Not only would that session have to be created properly, which
> >>>> I
> >>>> am
> >>>> not sure is happening when browsing in the protected resources, I would
> >>>> also
> >>>> need to access it on the server, so that I can save the currently logged
> >>>> in
> >>>> user into it.
> >>>>
> >>>> Is there a possibility to access the servlet session within the Keycloak
> >>>> context? If so, could you please share some code or point me to an API?
> >>>> --
> >>>>
> >>>> Mit freundlichen Gr??en,
> >>>>
> >>>> Christian Beikov
> >>>>
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 


From stian at redhat.com  Fri Jan  2 02:43:48 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 2 Jan 2015 02:43:48 -0500 (EST)
Subject: [keycloak-dev] reset-password-email web service proposal
	for	modification
In-Reply-To: <64C45159-330E-46AA-9444-BFE8C8CEAFDA@me.com>
References: <64C45159-330E-46AA-9444-BFE8C8CEAFDA@me.com>
Message-ID: <2048649949.2563880.1420184628316.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 1 January, 2015 2:26:12 PM
> Subject: [keycloak-dev] reset-password-email web service proposal for	modification
> 
> Hi
> 
> The reset-password-email rest web service sends an email to the user with the
> following content:
> Someone just requested to change your Keycloak account's password. If this
> was you, click on the link below to set a new password:
> http://localhost:8081/auth/realms/master/login-actions/password-reset?code=sI_NFQE1iMBoWhBnuoN674eHyBh5IMi_R2QbQ41X5iY.b1cc4d2a-d02d-4819-8156-17b2dd5e034d
> 
> The link above navigates to a form where the user has to enter his username
> or email address. After that he retrieves an other email with the following
> content:
> Someone just requested to change your Keycloak account's password. If this
> was you, click on the link below to set a new password:
> http://localhost:8081/auth/realms/master/login-actions/password-reset?key=Rhs73F1fSOznR-Z3sliNXSVKNBQeKyY8-4qlXqA5buI.b1cc4d2a-d02d-4819-8156-17b2dd5e034d
> 
> The user can than finally change his password and gets redirected to the
> keycloak account page.

That's not the correct behaviour. The user should just be asked to update password immediately. Please file a jira and do a PR for your fix.

Adding the redirect param is separate, so create another jira issue for that. If you'd like you can send a separate PR for it, but you also would need to specify client_id so Keycloak can verify it's a valid redirect_uri and generate a code that is associated with the correct client.

> 
> I think this process is a bit complicated. Isn?t it possible to send just one
> email? And it would be nice to pass a redirect URI to the web service.
> I implemented the described changes to show you what I mean:
> https://github.com/gerbermichi/keycloak/commit/1a892b70b1e788dfc5565d29f1eeeab80109d070
> 
> Best
> Michael
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From christian.beikov at gmail.com  Fri Jan  2 03:49:35 2015
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 02 Jan 2015 09:49:35 +0100
Subject: [keycloak-dev] Access original session
In-Reply-To: <792210726.2563607.1420184087778.JavaMail.zimbra@redhat.com>
References: <549FD512.9020705@gmail.com>
	<349569894.2249184.1419943101421.JavaMail.zimbra@redhat.com>
	<54A29E59.7030008@gmail.com>
	<1057182580.2251047.1419944384069.JavaMail.zimbra@redhat.com>
	<54A2BAE4.2050007@gmail.com>
	<792210726.2563607.1420184087778.JavaMail.zimbra@redhat.com>
Message-ID: <54A65B9F.7070006@gmail.com>

I tried it again with my application after deleting existing cookies and 
recreating the realm and indeed, it seems to use the underlying session.

I guess with all the long living cookies in my history something got 
messed up. Configuring the session cookie name in web.xml does not work 
as far as I can tell, but that's a different problem.

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 02.01.2015 um 08:34 schrieb Stian Thorgersen:
>
> ----- Original Message -----
>> From: "Christian Beikov" <christian.beikov at gmail.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 30 December, 2014 3:47:00 PM
>> Subject: Re: [keycloak-dev] Access original session
>>
>> I am using the following versions:
>>
>>    * Keycloak 1.0.4.Final
>>    * Wildfly 8.1.0.Final
>>
>> Also it doesn't respect the cookie settings of the web.xml. I tried to
>> configure a different name for the cookie just to test it, but it didn't
>> change. When navigating to "/whatever.xhtml" I suddenly get the
>> configured cookie set.
>> It seems as if the Keycloak adapters wrap the HttpServletRequest to
>> expose a different session map when working with secured resources.
>> Which demo are you talking about? I would love to try it out so that I
>> can confirm if it has something to do with my setup or Keycloak.
> Keycloak should just be using the underlying http session and not do anything special to it. Do you have the same problem with HTTP basic?
>
> The demo I'm referring to is the one that is bundled with the download, it's in examples/preconfigured-demo
>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 30.12.2014 um 13:59 schrieb Stian Thorgersen:
>>> ----- Original Message -----
>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 30 December, 2014 1:45:13 PM
>>>> Subject: Re: [keycloak-dev] Access original session
>>>>
>>>> Seems like my question wasn't clear enough.
>>>>
>>>> I have the following config in my web.xml
>>>>
>>>>        <security-constraint>
>>>>            <web-resource-collection>
>>>> <web-resource-name>Protected</web-resource-name>
>>>>                <url-pattern>/protected/*</url-pattern>
>>>>            </web-resource-collection>
>>>>            <auth-constraint>
>>>>                <role-name>user</role-name>
>>>>            </auth-constraint>
>>>>        </security-constraint>
>>>>
>>>>        <login-config>
>>>>            <auth-method>KEYCLOAK</auth-method>
>>>>            <realm-name>portfolio-webapp</realm-name>
>>>>        </login-config>
>>>>
>>>>        <security-role>
>>>>            <role-name>user</role-name>
>>>>        </security-role>
>>>>
>>>> Now when I navigate to e.g. "/protected/index.xhtml" I get redirected to
>>>> the Keycloak login. Unfortunately, the cookie which is set by the
>>>> Keycloak adapters after a succesful login, has the path "/protected"
>>>> set. When I navigate to "/whatever.xhtml" I obviously have no access to
>>>> the cookie since the browser doesn't send it.
>>>>
>>>> How am I supposed to access the logged in user outside of the protected
>>>> area?
>>>>
>>>> The session cookie (assuming you're talking about JSESSIONID) should be
>>>> set
>>>> to the context-path of your WAR not a specific protected resource.
>>>>
>>>> Unfortunately I am experiencing that it is set to a different path.
>>> Strange. I've just tried with our demo, which has a similar
>>> security-constraint to yours, and it sets it to the context-path of the
>>> WAR as expected.
>>>
>>> Keycloak doesn't set this cookie itself, that's sorted by the JEE
>>> container. Which Keycloak version and JEE server are you using?
>>>
>>>> Is your protected resources in the same WAR as the unprotected resources?
>>>>
>>>> Yes, it's all in the same WAR.
>>>>
>>>> Mit freundlichen Gr??en,
>>>> ------------------------------------------------------------------------
>>>> *Christian Beikov*
>>>> Am 30.12.2014 um 13:38 schrieb Stian Thorgersen:
>>>>> The session cookie (assuming you're talking about JSESSIONID) should be
>>>>> set
>>>>> to the context-path of your WAR not a specific protected resource. Is
>>>>> your
>>>>> protected resources in the same WAR as the unprotected resources?
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Sunday, 28 December, 2014 11:01:54 AM
>>>>>> Subject: [keycloak-dev] Access original session
>>>>>>
>>>>>> Hello there!"
>>>>>>
>>>>>> I have an application that has protected resources on the pattern
>>>>>> "/protected/*" and I receive a session cookie for the path "/protected",
>>>>>> which makes sense. Now my problem is, that I want the path of the cookie
>>>>>> to
>>>>>> be "/" so I can access the user information even outside of the
>>>>>> protected
>>>>>> resources.
>>>>>> Since I think this might introduce some problems, the only other way to
>>>>>> realize that I could think of is, to get access to the underlying
>>>>>> servlet
>>>>>> session. Not only would that session have to be created properly, which
>>>>>> I
>>>>>> am
>>>>>> not sure is happening when browsing in the protected resources, I would
>>>>>> also
>>>>>> need to access it on the server, so that I can save the currently logged
>>>>>> in
>>>>>> user into it.
>>>>>>
>>>>>> Is there a possibility to access the servlet session within the Keycloak
>>>>>> context? If so, could you please share some code or point me to an API?
>>>>>> --
>>>>>>
>>>>>> Mit freundlichen Gr??en,
>>>>>>
>>>>>> Christian Beikov
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20150102/036ec08f/attachment.html 

From stian at redhat.com  Mon Jan  5 06:47:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 5 Jan 2015 06:47:49 -0500 (EST)
Subject: [keycloak-dev] 1.1.0.Final release
In-Reply-To: <1529084170.3365400.1420457848727.JavaMail.zimbra@redhat.com>
Message-ID: <1217275381.3369589.1420458469584.JavaMail.zimbra@redhat.com>

Happy New Years everyone :)

I'd like to release 1.1.0.Final this week or early next week. 

There's still a few issues outstanding, so once you've recovered from Christmas and New Years go grab an issue from https://issues.jboss.org/issues/?filter=12322375.

Identity Brokering is a relatively big feature, including refactoring of social login, so we'll push that to 1.2.0.Beta1. As the Node.js adapter isn't quite ready that'll also be pushed for 1.2.0.Beta1.

From stian at redhat.com  Mon Jan  5 07:18:30 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 5 Jan 2015 07:18:30 -0500 (EST)
Subject: [keycloak-dev] Only redirect on GET
In-Reply-To: <1437717965.3380452.1420460240124.JavaMail.zimbra@redhat.com>
Message-ID: <1006865949.3380758.1420460310017.JavaMail.zimbra@redhat.com>

With regards to:

https://issues.jboss.org/browse/KEYCLOAK-881
https://issues.jboss.org/browse/KEYCLOAK-878

Are they not both caused by the adapter redirecting to login page on non-GET requests? Would it not make sense to only do a redirect for GET requests and return a 401 for other request types?

From bburke at redhat.com  Mon Jan  5 08:31:18 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 05 Jan 2015 08:31:18 -0500
Subject: [keycloak-dev] Only redirect on GET
In-Reply-To: <1006865949.3380758.1420460310017.JavaMail.zimbra@redhat.com>
References: <1006865949.3380758.1420460310017.JavaMail.zimbra@redhat.com>
Message-ID: <54AA9226.60200@redhat.com>

One problem that I fixed was that the adapter wasn't correctly saving 
non-GET requests in the Http Session.  Only problem is that Jetty can 
only support saving POST form requests.  I need to put in a test for 878 
for PUT requests...

BTW, I think all their GWT problems are a result of not setting up GWT 
to send HTTP requests with auth headers.

On 1/5/2015 7:18 AM, Stian Thorgersen wrote:
> With regards to:
>
> https://issues.jboss.org/browse/KEYCLOAK-881
> https://issues.jboss.org/browse/KEYCLOAK-878
>
> Are they not both caused by the adapter redirecting to login page on non-GET requests? Would it not make sense to only do a redirect for GET requests and return a 401 for other request types?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Mon Jan  5 08:47:44 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 5 Jan 2015 08:47:44 -0500 (EST)
Subject: [keycloak-dev] Only redirect on GET
In-Reply-To: <54AA9226.60200@redhat.com>
References: <1006865949.3380758.1420460310017.JavaMail.zimbra@redhat.com>
	<54AA9226.60200@redhat.com>
Message-ID: <1080661656.3440309.1420465664314.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 5 January, 2015 2:31:18 PM
> Subject: Re: [keycloak-dev] Only redirect on GET
> 
> One problem that I fixed was that the adapter wasn't correctly saving
> non-GET requests in the Http Session.  Only problem is that Jetty can
> only support saving POST form requests.  I need to put in a test for 878
> for PUT requests...

Saving non-GET requests in the HTTP session opens up an easy DoS attack though. Someone can just POST a few big forms to fill up the servers memory.

Would it not be simpler to just do login redirect on GET?

> 
> BTW, I think all their GWT problems are a result of not setting up GWT
> to send HTTP requests with auth headers.
> 
> On 1/5/2015 7:18 AM, Stian Thorgersen wrote:
> > With regards to:
> >
> > https://issues.jboss.org/browse/KEYCLOAK-881
> > https://issues.jboss.org/browse/KEYCLOAK-878
> >
> > Are they not both caused by the adapter redirecting to login page on
> > non-GET requests? Would it not make sense to only do a redirect for GET
> > requests and return a 401 for other request types?
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Mon Jan  5 09:55:33 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 05 Jan 2015 09:55:33 -0500
Subject: [keycloak-dev] Only redirect on GET
In-Reply-To: <1080661656.3440309.1420465664314.JavaMail.zimbra@redhat.com>
References: <1006865949.3380758.1420460310017.JavaMail.zimbra@redhat.com>
	<54AA9226.60200@redhat.com>
	<1080661656.3440309.1420465664314.JavaMail.zimbra@redhat.com>
Message-ID: <54AAA5E5.7000303@redhat.com>



On 1/5/2015 8:47 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 5 January, 2015 2:31:18 PM
>> Subject: Re: [keycloak-dev] Only redirect on GET
>>
>> One problem that I fixed was that the adapter wasn't correctly saving
>> non-GET requests in the Http Session.  Only problem is that Jetty can
>> only support saving POST form requests.  I need to put in a test for 878
>> for PUT requests...
>
> Saving non-GET requests in the HTTP session opens up an easy DoS attack though. Someone can just POST a few big forms to fill up the servers memory.
>
> Would it not be simpler to just do login redirect on GET?
>

All servlet containers do this for form login.  They also all have 
configurable limits of what can be cached.  Default for undertow is like 
16k I think (or is it 1k, i don't remember).


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

From psilva at redhat.com  Tue Jan  6 06:33:30 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 Jan 2015 06:33:30 -0500 (EST)
Subject: [keycloak-dev] Email constraint violation when updating profile
In-Reply-To: <731700248.4382815.1420543904922.JavaMail.zimbra@redhat.com>
Message-ID: <468373684.4383040.1420544010622.JavaMail.zimbra@redhat.com>

Hi,

    Would like to know your thoughts on KEYCLOAK-924 [1].

    Looks like there is an issue with the "Update Profile" workflow that also impacts social authentication and account linking.

Regards.
Pedro Igor

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

From stian at redhat.com  Tue Jan  6 06:53:56 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 Jan 2015 06:53:56 -0500 (EST)
Subject: [keycloak-dev] Email constraint violation when updating profile
In-Reply-To: <468373684.4383040.1420544010622.JavaMail.zimbra@redhat.com>
References: <468373684.4383040.1420544010622.JavaMail.zimbra@redhat.com>
Message-ID: <1781545257.4168036.1420545236214.JavaMail.zimbra@redhat.com>

This is a corner case and we can safely ignore it until someone complains about it. There are also already ways to work around it:

1) User logs into account console, removes the social/broker link, logs in to the other account and adds the social link
2) User talks to admin, admin deletes one account (or removes social/broker link), then user can link to existing account

When we implemented linking of accounts in the first place me and Marek discussed this issue over and over. Whichever solution we came up with had issues, both technical and usability issues. So end of the day we decided that as there's a work around to it, and that it won't be a very common problem, we could safely ignore it.

With regards to the proposed solution, that was one we visited, but it has several issues. Creating the user after doesn't work as we need to have somewhere to store the information and it would also add more complexity to required actions. Also, it doesn't work if update profile is not required on first login or if email is not required. In either of those cases you end up with at some point in the future the user may try to update the account with their email and get the same problem.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 6 January, 2015 12:33:30 PM
> Subject: [keycloak-dev] Email constraint violation when updating profile
> 
> Hi,
> 
>     Would like to know your thoughts on KEYCLOAK-924 [1].
> 
>     Looks like there is an issue with the "Update Profile" workflow that also
>     impacts social authentication and account linking.
> 
> Regards.
> Pedro Igor
> 
> [1] https://issues.jboss.org/browse/KEYCLOAK-924
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jan  6 07:48:20 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 Jan 2015 07:48:20 -0500 (EST)
Subject: [keycloak-dev] Splitting subsystem into two
In-Reply-To: <1291408370.4182655.1420548470044.JavaMail.zimbra@redhat.com>
Message-ID: <2067469498.4182750.1420548500352.JavaMail.zimbra@redhat.com>

https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be cleaner to split the subsystem in two, one for the server and another for the adapter.

From ssilvert at redhat.com  Tue Jan  6 08:12:52 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 06 Jan 2015 08:12:52 -0500
Subject: [keycloak-dev] Splitting subsystem into two
In-Reply-To: <2067469498.4182750.1420548500352.JavaMail.zimbra@redhat.com>
References: <2067469498.4182750.1420548500352.JavaMail.zimbra@redhat.com>
Message-ID: <54ABDF54.2010809@redhat.com>

You may be right.  I think the decision comes down to answering the 
question, "Is it ever advantageous to have the server and adapter in the 
same classloader space (module)?"  The answer will hopefully become 
clear once I get a chance to talk to you in more detail about seamless 
adapter configuration.

I've got the client part working where a template configuration is 
applied to any unsecured WAR.  We just need to decide how the subsystem 
will register the application with the server.  That's the part where it 
might be very helpful to have both in the same module so we can just 
make direct calls.  Even so, we can't really do that today without 
significant refactoring.

On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be cleaner to split the subsystem in two, one for the server and another for the adapter.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From psilva at redhat.com  Tue Jan  6 08:14:21 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 Jan 2015 08:14:21 -0500 (EST)
Subject: [keycloak-dev] Email constraint violation when updating profile
In-Reply-To: <1781545257.4168036.1420545236214.JavaMail.zimbra@redhat.com>
References: <468373684.4383040.1420544010622.JavaMail.zimbra@redhat.com>
	<1781545257.4168036.1420545236214.JavaMail.zimbra@redhat.com>
Message-ID: <687488606.4464914.1420550061009.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, January 6, 2015 9:53:56 AM
> Subject: Re: [keycloak-dev] Email constraint violation when updating profile
> 
> This is a corner case and we can safely ignore it until someone complains
> about it. There are also already ways to work around it:
> 
> 1) User logs into account console, removes the social/broker link, logs in to
> the other account and adds the social link
> 2) User talks to admin, admin deletes one account (or removes social/broker
> link), then user can link to existing account
> 
> When we implemented linking of accounts in the first place me and Marek
> discussed this issue over and over. Whichever solution we came up with had
> issues, both technical and usability issues. So end of the day we decided
> that as there's a work around to it, and that it won't be a very common
> problem, we could safely ignore it.

Not sure if you can safely ignore it. Users will get an ugly error on their browser, instead of a proper error message. If you just check for a duplicate email in org.keycloak.services.resources.LoginActionsService#updateProfile, that would be enough to avoid the error. And this is should be very simple.

> 
> With regards to the proposed solution, that was one we visited, but it has
> several issues. Creating the user after doesn't work as we need to have
> somewhere to store the information and it would also add more complexity to
> required actions. Also, it doesn't work if update profile is not required on
> first login or if email is not required. In either of those cases you end up
> with at some point in the future the user may try to update the account with
> their email and get the same problem.

Not really, the validation above should be enough.

Still not convinced :) I understand the technical blockers, but they should not be blockers to offer a better usability.

>From a business perspective, the workflow is wrong. You can not store the user before getting the input from the user when update profile is enabled. That is what you see around the web and what KC does partially.

> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, 6 January, 2015 12:33:30 PM
> > Subject: [keycloak-dev] Email constraint violation when updating profile
> > 
> > Hi,
> > 
> >     Would like to know your thoughts on KEYCLOAK-924 [1].
> > 
> >     Looks like there is an issue with the "Update Profile" workflow that
> >     also
> >     impacts social authentication and account linking.
> > 
> > Regards.
> > Pedro Igor
> > 
> > [1] https://issues.jboss.org/browse/KEYCLOAK-924
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From stian at redhat.com  Tue Jan  6 08:25:45 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 Jan 2015 08:25:45 -0500 (EST)
Subject: [keycloak-dev] Email constraint violation when updating profile
In-Reply-To: <687488606.4464914.1420550061009.JavaMail.zimbra@redhat.com>
References: <468373684.4383040.1420544010622.JavaMail.zimbra@redhat.com>
	<1781545257.4168036.1420545236214.JavaMail.zimbra@redhat.com>
	<687488606.4464914.1420550061009.JavaMail.zimbra@redhat.com>
Message-ID: <1960459369.4194728.1420550745899.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 6 January, 2015 2:14:21 PM
> Subject: Re: [keycloak-dev] Email constraint violation when updating profile
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, January 6, 2015 9:53:56 AM
> > Subject: Re: [keycloak-dev] Email constraint violation when updating
> > profile
> > 
> > This is a corner case and we can safely ignore it until someone complains
> > about it. There are also already ways to work around it:
> > 
> > 1) User logs into account console, removes the social/broker link, logs in
> > to
> > the other account and adds the social link
> > 2) User talks to admin, admin deletes one account (or removes social/broker
> > link), then user can link to existing account
> > 
> > When we implemented linking of accounts in the first place me and Marek
> > discussed this issue over and over. Whichever solution we came up with had
> > issues, both technical and usability issues. So end of the day we decided
> > that as there's a work around to it, and that it won't be a very common
> > problem, we could safely ignore it.
> 
> Not sure if you can safely ignore it. Users will get an ugly error on their
> browser, instead of a proper error message. If you just check for a
> duplicate email in
> org.keycloak.services.resources.LoginActionsService#updateProfile, that
> would be enough to avoid the error. And this is should be very simple.

Agree it should be a proper error message. I didn't get that was the problem. It shouldn't check for duplicate email though, it should rely on db constraints as otherwise you can't guarantee it doesn't exist, but still an easy fix. Can you create a separate JIRA issue for it with and we'll fix for 1.1.0.Final?

> 
> > 
> > With regards to the proposed solution, that was one we visited, but it has
> > several issues. Creating the user after doesn't work as we need to have
> > somewhere to store the information and it would also add more complexity to
> > required actions. Also, it doesn't work if update profile is not required
> > on
> > first login or if email is not required. In either of those cases you end
> > up
> > with at some point in the future the user may try to update the account
> > with
> > their email and get the same problem.
> 
> Not really, the validation above should be enough.
> 
> Still not convinced :) I understand the technical blockers, but they should
> not be blockers to offer a better usability.
> 
> From a business perspective, the workflow is wrong. You can not store the
> user before getting the input from the user when update profile is enabled.
> That is what you see around the web and what KC does partially.

You can argue which workflow is better, but both are perfectly valid. There's nothing wrong with storing the user before update profile. If there's a update profile required action associated with the account the user is not able to use the account until the profile has been updated. Absolutely nothing wrong with the current flow, other than the potential of the user wanting to set an email address that already exists, which there are many other much simpler solutions to than what you are proposing. End of the day you'll provide the same error message to the user, so from a usability perspective there's no difference whether or not the it's stored in the db or not.

> 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, 6 January, 2015 12:33:30 PM
> > > Subject: [keycloak-dev] Email constraint violation when updating profile
> > > 
> > > Hi,
> > > 
> > >     Would like to know your thoughts on KEYCLOAK-924 [1].
> > > 
> > >     Looks like there is an issue with the "Update Profile" workflow that
> > >     also
> > >     impacts social authentication and account linking.
> > > 
> > > Regards.
> > > Pedro Igor
> > > 
> > > [1] https://issues.jboss.org/browse/KEYCLOAK-924
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

From bburke at redhat.com  Tue Jan  6 08:43:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 Jan 2015 08:43:12 -0500
Subject: [keycloak-dev] Splitting subsystem into two
In-Reply-To: <54ABDF54.2010809@redhat.com>
References: <2067469498.4182750.1420548500352.JavaMail.zimbra@redhat.com>
	<54ABDF54.2010809@redhat.com>
Message-ID: <54ABE670.3020700@redhat.com>

If they are separate, why couldn't they be in the same classloader 
space?  They would share dependencies.

On 1/6/2015 8:12 AM, Stan Silvert wrote:
> You may be right.  I think the decision comes down to answering the
> question, "Is it ever advantageous to have the server and adapter in the
> same classloader space (module)?"  The answer will hopefully become
> clear once I get a chance to talk to you in more detail about seamless
> adapter configuration.
>
> I've got the client part working where a template configuration is
> applied to any unsecured WAR.  We just need to decide how the subsystem
> will register the application with the server.  That's the part where it
> might be very helpful to have both in the same module so we can just
> make direct calls.  Even so, we can't really do that today without
> significant refactoring.
>
> On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
>> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be cleaner to split the subsystem in two, one for the server and another for the adapter.
>> _______________________________________________
>> 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 stian at redhat.com  Tue Jan  6 08:51:43 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 6 Jan 2015 08:51:43 -0500 (EST)
Subject: [keycloak-dev] Splitting subsystem into two
In-Reply-To: <54ABE670.3020700@redhat.com>
References: <2067469498.4182750.1420548500352.JavaMail.zimbra@redhat.com>
	<54ABDF54.2010809@redhat.com> <54ABE670.3020700@redhat.com>
Message-ID: <1027307900.4211593.1420552303680.JavaMail.zimbra@redhat.com>

We should move all libs to modules, so would be same classloader space right? Module class-loaders are shared by default are they not?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 6 January, 2015 2:43:12 PM
> Subject: Re: [keycloak-dev] Splitting subsystem into two
> 
> If they are separate, why couldn't they be in the same classloader
> space?  They would share dependencies.
> 
> On 1/6/2015 8:12 AM, Stan Silvert wrote:
> > You may be right.  I think the decision comes down to answering the
> > question, "Is it ever advantageous to have the server and adapter in the
> > same classloader space (module)?"  The answer will hopefully become
> > clear once I get a chance to talk to you in more detail about seamless
> > adapter configuration.
> >
> > I've got the client part working where a template configuration is
> > applied to any unsecured WAR.  We just need to decide how the subsystem
> > will register the application with the server.  That's the part where it
> > might be very helpful to have both in the same module so we can just
> > make direct calls.  Even so, we can't really do that today without
> > significant refactoring.
> >
> > On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
> >> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be
> >> cleaner to split the subsystem in two, one for the server and another for
> >> the adapter.
> >> _______________________________________________
> >> 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 psilva at redhat.com  Tue Jan  6 08:51:54 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 6 Jan 2015 08:51:54 -0500 (EST)
Subject: [keycloak-dev] Email constraint violation when updating profile
In-Reply-To: <1960459369.4194728.1420550745899.JavaMail.zimbra@redhat.com>
References: <468373684.4383040.1420544010622.JavaMail.zimbra@redhat.com>
	<1781545257.4168036.1420545236214.JavaMail.zimbra@redhat.com>
	<687488606.4464914.1420550061009.JavaMail.zimbra@redhat.com>
	<1960459369.4194728.1420550745899.JavaMail.zimbra@redhat.com>
Message-ID: <825812049.4524020.1420552314889.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, January 6, 2015 11:25:45 AM
> Subject: Re: [keycloak-dev] Email constraint violation when updating profile
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Tuesday, 6 January, 2015 2:14:21 PM
> > Subject: Re: [keycloak-dev] Email constraint violation when updating
> > profile
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Tuesday, January 6, 2015 9:53:56 AM
> > > Subject: Re: [keycloak-dev] Email constraint violation when updating
> > > profile
> > > 
> > > This is a corner case and we can safely ignore it until someone complains
> > > about it. There are also already ways to work around it:
> > > 
> > > 1) User logs into account console, removes the social/broker link, logs
> > > in
> > > to
> > > the other account and adds the social link
> > > 2) User talks to admin, admin deletes one account (or removes
> > > social/broker
> > > link), then user can link to existing account
> > > 
> > > When we implemented linking of accounts in the first place me and Marek
> > > discussed this issue over and over. Whichever solution we came up with
> > > had
> > > issues, both technical and usability issues. So end of the day we decided
> > > that as there's a work around to it, and that it won't be a very common
> > > problem, we could safely ignore it.
> > 
> > Not sure if you can safely ignore it. Users will get an ugly error on their
> > browser, instead of a proper error message. If you just check for a
> > duplicate email in
> > org.keycloak.services.resources.LoginActionsService#updateProfile, that
> > would be enough to avoid the error. And this is should be very simple.
> 
> Agree it should be a proper error message. I didn't get that was the problem.
> It shouldn't check for duplicate email though, it should rely on db
> constraints as otherwise you can't guarantee it doesn't exist, but still an
> easy fix. Can you create a separate JIRA issue for it with and we'll fix for
> 1.1.0.Final?

Sure, I`ll. Thanks.

> 
> > 
> > > 
> > > With regards to the proposed solution, that was one we visited, but it
> > > has
> > > several issues. Creating the user after doesn't work as we need to have
> > > somewhere to store the information and it would also add more complexity
> > > to
> > > required actions. Also, it doesn't work if update profile is not required
> > > on
> > > first login or if email is not required. In either of those cases you end
> > > up
> > > with at some point in the future the user may try to update the account
> > > with
> > > their email and get the same problem.
> > 
> > Not really, the validation above should be enough.
> > 
> > Still not convinced :) I understand the technical blockers, but they should
> > not be blockers to offer a better usability.
> > 
> > From a business perspective, the workflow is wrong. You can not store the
> > user before getting the input from the user when update profile is enabled.
> > That is what you see around the web and what KC does partially.
> 
> You can argue which workflow is better, but both are perfectly valid. There's
> nothing wrong with storing the user before update profile. If there's a
> update profile required action associated with the account the user is not
> able to use the account until the profile has been updated. Absolutely
> nothing wrong with the current flow, other than the potential of the user
> wanting to set an email address that already exists, which there are many
> other much simpler solutions to than what you are proposing. End of the day
> you'll provide the same error message to the user, so from a usability
> perspective there's no difference whether or not the it's stored in the db
> or not.
> 
> > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > Sent: Tuesday, 6 January, 2015 12:33:30 PM
> > > > Subject: [keycloak-dev] Email constraint violation when updating
> > > > profile
> > > > 
> > > > Hi,
> > > > 
> > > >     Would like to know your thoughts on KEYCLOAK-924 [1].
> > > > 
> > > >     Looks like there is an issue with the "Update Profile" workflow
> > > >     that
> > > >     also
> > > >     impacts social authentication and account linking.
> > > > 
> > > > Regards.
> > > > Pedro Igor
> > > > 
> > > > [1] https://issues.jboss.org/browse/KEYCLOAK-924
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > 
> > 
> 

From ssilvert at redhat.com  Tue Jan  6 09:00:11 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 06 Jan 2015 09:00:11 -0500
Subject: [keycloak-dev] Splitting subsystem into two
In-Reply-To: <1027307900.4211593.1420552303680.JavaMail.zimbra@redhat.com>
References: <2067469498.4182750.1420548500352.JavaMail.zimbra@redhat.com>
	<54ABDF54.2010809@redhat.com> <54ABE670.3020700@redhat.com>
	<1027307900.4211593.1420552303680.JavaMail.zimbra@redhat.com>
Message-ID: <54ABEA6B.6020106@redhat.com>

I'm not totally sure what can be shared among subsystems.  Maybe I'm 
overthinking it.

As long as the server is deployed as a WAR then there will be 
restrictions on that by default.  I don't know of any way to grab an 
object from a WAR classloader and start making calls on it from a 
subsystem.  But maybe it can be done.  I've never tried.

On 1/6/2015 8:51 AM, Stian Thorgersen wrote:
> We should move all libs to modules, so would be same classloader space right? Module class-loaders are shared by default are they not?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 6 January, 2015 2:43:12 PM
>> Subject: Re: [keycloak-dev] Splitting subsystem into two
>>
>> If they are separate, why couldn't they be in the same classloader
>> space?  They would share dependencies.
>>
>> On 1/6/2015 8:12 AM, Stan Silvert wrote:
>>> You may be right.  I think the decision comes down to answering the
>>> question, "Is it ever advantageous to have the server and adapter in the
>>> same classloader space (module)?"  The answer will hopefully become
>>> clear once I get a chance to talk to you in more detail about seamless
>>> adapter configuration.
>>>
>>> I've got the client part working where a template configuration is
>>> applied to any unsecured WAR.  We just need to decide how the subsystem
>>> will register the application with the server.  That's the part where it
>>> might be very helpful to have both in the same module so we can just
>>> make direct calls.  Even so, we can't really do that today without
>>> significant refactoring.
>>>
>>> On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
>>>> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be
>>>> cleaner to split the subsystem in two, one for the server and another for
>>>> the adapter.
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue Jan  6 09:07:35 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 06 Jan 2015 09:07:35 -0500
Subject: [keycloak-dev] Splitting subsystem into two
In-Reply-To: <54ABEA6B.6020106@redhat.com>
References: <2067469498.4182750.1420548500352.JavaMail.zimbra@redhat.com>	<54ABDF54.2010809@redhat.com>
	<54ABE670.3020700@redhat.com>	<1027307900.4211593.1420552303680.JavaMail.zimbra@redhat.com>
	<54ABEA6B.6020106@redhat.com>
Message-ID: <54ABEC27.1050406@redhat.com>

As long as shared code is in modules there should be no problem.

On 1/6/2015 9:00 AM, Stan Silvert wrote:
> I'm not totally sure what can be shared among subsystems.  Maybe I'm
> overthinking it.
>
> As long as the server is deployed as a WAR then there will be
> restrictions on that by default.  I don't know of any way to grab an
> object from a WAR classloader and start making calls on it from a
> subsystem.  But maybe it can be done.  I've never tried.
>
> On 1/6/2015 8:51 AM, Stian Thorgersen wrote:
>> We should move all libs to modules, so would be same classloader space right? Module class-loaders are shared by default are they not?
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 6 January, 2015 2:43:12 PM
>>> Subject: Re: [keycloak-dev] Splitting subsystem into two
>>>
>>> If they are separate, why couldn't they be in the same classloader
>>> space?  They would share dependencies.
>>>
>>> On 1/6/2015 8:12 AM, Stan Silvert wrote:
>>>> You may be right.  I think the decision comes down to answering the
>>>> question, "Is it ever advantageous to have the server and adapter in the
>>>> same classloader space (module)?"  The answer will hopefully become
>>>> clear once I get a chance to talk to you in more detail about seamless
>>>> adapter configuration.
>>>>
>>>> I've got the client part working where a template configuration is
>>>> applied to any unsecured WAR.  We just need to decide how the subsystem
>>>> will register the application with the server.  That's the part where it
>>>> might be very helpful to have both in the same module so we can just
>>>> make direct calls.  Even so, we can't really do that today without
>>>> significant refactoring.
>>>>
>>>> On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
>>>>> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be
>>>>> cleaner to split the subsystem in two, one for the server and another for
>>>>> the adapter.
>>>>> _______________________________________________
>>>>> 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
>>>
>> _______________________________________________
>> 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 stian at redhat.com  Wed Jan  7 03:14:18 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 7 Jan 2015 03:14:18 -0500 (EST)
Subject: [keycloak-dev] Splitting subsystem into two
In-Reply-To: <54ABEC27.1050406@redhat.com>
References: <2067469498.4182750.1420548500352.JavaMail.zimbra@redhat.com>
	<54ABDF54.2010809@redhat.com> <54ABE670.3020700@redhat.com>
	<1027307900.4211593.1420552303680.JavaMail.zimbra@redhat.com>
	<54ABEA6B.6020106@redhat.com> <54ABEC27.1050406@redhat.com>
Message-ID: <21335316.4802277.1420618458703.JavaMail.zimbra@redhat.com>

As I see it there's two reasons to split the subsystem in two:

a) Reduce size of adapter dl
b) Make it more obvious to users that there are two parts

I'm not convinced it's required to split into two subsystems for either of those. a) can be resolved by moving libs into modules and making sure we only include the required modules for the adapter. b) can be resolved by making sure we have a sensible error message if someone tries to start an auth-server with the adapter only dl.

So I reckon we don't split the subsystem, but leave as is. For 1.2.0.Beta1 we'll move all jars from the WAR into modules and make sure only the required modules are included in the adapter download.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 6 January, 2015 3:07:35 PM
> Subject: Re: [keycloak-dev] Splitting subsystem into two
> 
> As long as shared code is in modules there should be no problem.
> 
> On 1/6/2015 9:00 AM, Stan Silvert wrote:
> > I'm not totally sure what can be shared among subsystems.  Maybe I'm
> > overthinking it.
> >
> > As long as the server is deployed as a WAR then there will be
> > restrictions on that by default.  I don't know of any way to grab an
> > object from a WAR classloader and start making calls on it from a
> > subsystem.  But maybe it can be done.  I've never tried.
> >
> > On 1/6/2015 8:51 AM, Stian Thorgersen wrote:
> >> We should move all libs to modules, so would be same classloader space
> >> right? Module class-loaders are shared by default are they not?
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, 6 January, 2015 2:43:12 PM
> >>> Subject: Re: [keycloak-dev] Splitting subsystem into two
> >>>
> >>> If they are separate, why couldn't they be in the same classloader
> >>> space?  They would share dependencies.
> >>>
> >>> On 1/6/2015 8:12 AM, Stan Silvert wrote:
> >>>> You may be right.  I think the decision comes down to answering the
> >>>> question, "Is it ever advantageous to have the server and adapter in the
> >>>> same classloader space (module)?"  The answer will hopefully become
> >>>> clear once I get a chance to talk to you in more detail about seamless
> >>>> adapter configuration.
> >>>>
> >>>> I've got the client part working where a template configuration is
> >>>> applied to any unsecured WAR.  We just need to decide how the subsystem
> >>>> will register the application with the server.  That's the part where it
> >>>> might be very helpful to have both in the same module so we can just
> >>>> make direct calls.  Even so, we can't really do that today without
> >>>> significant refactoring.
> >>>>
> >>>> On 1/6/2015 7:48 AM, Stian Thorgersen wrote:
> >>>>> https://issues.jboss.org/browse/KEYCLOAK-872 made me think it might be
> >>>>> cleaner to split the subsystem in two, one for the server and another
> >>>>> for
> >>>>> the adapter.
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >> _______________________________________________
> >> 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 bburke at redhat.com  Wed Jan  7 19:44:01 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 07 Jan 2015 19:44:01 -0500
Subject: [keycloak-dev] Build on top of Vert.x?
Message-ID: <54ADD2D1.8020508@redhat.com>

Don't care that much at all about AIO, but what is compelling to me 
about Vert.x is that it is a polyglot platform.  If our SPIs could be 
written in any language and deployed easily this would be a huge win and 
could potential bring together very diverse communities (node.js and 
linux-python-admins).

Something to think about for Keycloak 2.0.

Bill

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

From bburke at redhat.com  Wed Jan  7 20:14:51 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 07 Jan 2015 20:14:51 -0500
Subject: [keycloak-dev] oauth vulnerabilities
Message-ID: <54ADDA0B.2060906@redhat.com>

http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html

I think we're pretty good, the ones I worry about is relative urls in 
redirect URI checks i.e.

"http://cloud.com/provisioned/good-site/../hacker-site"

I'll log a bug for this if you agree that relative redirect URLs 
shouldn't be allowed. (Those containing "." and "..")

Another really dangerous thing that we do is have full-scope-allowed set 
to true by default.  If a rogue client gets registered, they pretty much 
have access to every single application the user can access with all of 
their privileges.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Jan  7 20:31:59 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 07 Jan 2015 20:31:59 -0500
Subject: [keycloak-dev] oauth vulnerabilities
In-Reply-To: <54ADDA0B.2060906@redhat.com>
References: <54ADDA0B.2060906@redhat.com>
Message-ID: <54ADDE0F.4000700@redhat.com>

Read this one, specifically that attack on github (you have to scroll 
down a bit):

http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html

wildcard redirect uri patterns are pretty scary!

On 1/7/2015 8:14 PM, Bill Burke wrote:
> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html
>
> I think we're pretty good, the ones I worry about is relative urls in
> redirect URI checks i.e.
>
> "http://cloud.com/provisioned/good-site/../hacker-site"
>
> I'll log a bug for this if you agree that relative redirect URLs
> shouldn't be allowed. (Those containing "." and "..")
>
> Another really dangerous thing that we do is have full-scope-allowed set
> to true by default.  If a rogue client gets registered, they pretty much
> have access to every single application the user can access with all of
> their privileges.
>

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

From stian at redhat.com  Thu Jan  8 03:33:22 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 8 Jan 2015 03:33:22 -0500 (EST)
Subject: [keycloak-dev] Build on top of Vert.x?
In-Reply-To: <54ADD2D1.8020508@redhat.com>
References: <54ADD2D1.8020508@redhat.com>
Message-ID: <159550871.5491311.1420706002566.JavaMail.zimbra@redhat.com>

Interesting idea, especially with regards to providers. In general we really do need to improve on how providers are written and configured.

We shouldn't forget about JEE either though. JEE has a lot to offer application developers that Vert.x doesn't.

Not convinced we should rewrite Keycloak to run on Vert.x. Instead I'd say we should provide hooks into Vert.x and other containers (JEE) to allow users to write providers in whatever they want.

The #1 thing to think about for Keycloak 2.0 IMO is customization. What parts should be customizable and how do we best allow users to do that?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 8 January, 2015 1:44:01 AM
> Subject: [keycloak-dev] Build on top of Vert.x?
> 
> Don't care that much at all about AIO, but what is compelling to me
> about Vert.x is that it is a polyglot platform.  If our SPIs could be
> written in any language and deployed easily this would be a huge win and
> could potential bring together very diverse communities (node.js and
> linux-python-admins).
> 
> Something to think about for Keycloak 2.0.
> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jan  8 05:25:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 8 Jan 2015 05:25:19 -0500 (EST)
Subject: [keycloak-dev] Keycloak in JBoss projects
In-Reply-To: <1453502273.5536270.1420712089583.JavaMail.zimbra@redhat.com>
Message-ID: <1576996562.5540472.1420712719396.JavaMail.zimbra@redhat.com>

There's a lot of JBoss projects already integrating or looking at using Keycloak:

* AeroGear UPS
* LiveOak
* RTGov
* Hawt.io
* Fabric8
* Fuse
* S-RAMP
* APIMan
* ...

I think now is the time to make sure we can provide the best and consistent experience for all projects. With that regards there's improvements we can make:

* Embeddable Keycloak - provide a slimmed down profile of Keycloak that can easily be embedded into existing projects. The big question here is should we support deploying to other containers than WildFly? I reckon as long as projects support other projects and we want to be the main auth solution we do. I'd hate to see projects having to provide alternative mechanisms themselves to continue to support Tomcat for example
* External Keycloak - make it simpler to link a project to an external Keycloak, including sharing the master realm for SSO to all consoles
* Configuration - for both embeddable and external we need to make it easier for projects to bootstrap and update application configuration (for example if hostname changes)
* Unified console - we need to align better with PatternFly and RCUE. We should also provide a mechanism for linking between consoles

From mposolda at redhat.com  Thu Jan  8 07:14:22 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 08 Jan 2015 13:14:22 +0100
Subject: [keycloak-dev] LoginProtocol endpoints not shown in rest api
	documentation
Message-ID: <54AE749E.3050609@redhat.com>

Looks that with LoginProtocol abstraction, the endpoints for 
OpenIDConnectService and SamlService are missing in the rest api docs 
http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/rest-api/overview-index.html 
. I've created jira https://issues.jboss.org/browse/KEYCLOAK-946 .

There's dummy solution to explicitly add method for each protocol into 
RealmsResource like this 
https://github.com/mposolda/keycloak/commit/f7391fef849aef5a8537ab563b37b7b3835ead0a 
. But unfortunately SamlService is not available to "services" project, 
so it works just for OpenID :-(

Does it worth to do some refactoring because of this? Any better idea?

Marek

From alain at rexorient.com  Thu Jan  8 13:02:15 2015
From: alain at rexorient.com (Alain Penders)
Date: Thu, 8 Jan 2015 11:02:15 -0700
Subject: [keycloak-dev] Build on top of Vert.x?
In-Reply-To: <159550871.5491311.1420706002566.JavaMail.zimbra@redhat.com>
References: <54ADD2D1.8020508@redhat.com>
	<159550871.5491311.1420706002566.JavaMail.zimbra@redhat.com>
Message-ID: <CAMtP743wLCdK+zu1fYQNOj8LNnUd0LTGk-yr4-Rt0E_dppWZrg@mail.gmail.com>

I, for one, would enjoy seeing Keycloak running on Vert.x.  I moved my
application from WildFly to Vert.x, and now the only reason I'm still
running WildFly is Keycloak.

I started working on a full Vert.x Adapter, but eventually decided it was
easier to just stick to plain bearer auth.  (Also because my front-end is
GWT + keycloak.js.)

Also, any recommendations for securing websockets?  I use the browser-side
EventBus in Vert.x, which uses websockets to exchange messages with the
server.  Since I want to be able to pass the accessToken to various Vert.x
services, it needs to remain uptodate and not be the one used to establish
the connection.  I implemented a basic system to handle this in Vert.x, but
I assume the same issue would exist for anyone using WebSockets to connect
to WildFly.

Alain


On Thu, Jan 8, 2015 at 1:33 AM, Stian Thorgersen <stian at redhat.com> wrote:

> Interesting idea, especially with regards to providers. In general we
> really do need to improve on how providers are written and configured.
>
> We shouldn't forget about JEE either though. JEE has a lot to offer
> application developers that Vert.x doesn't.
>
> Not convinced we should rewrite Keycloak to run on Vert.x. Instead I'd say
> we should provide hooks into Vert.x and other containers (JEE) to allow
> users to write providers in whatever they want.
>
> The #1 thing to think about for Keycloak 2.0 IMO is customization. What
> parts should be customizable and how do we best allow users to do that?
>
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 8 January, 2015 1:44:01 AM
> > Subject: [keycloak-dev] Build on top of Vert.x?
> >
> > Don't care that much at all about AIO, but what is compelling to me
> > about Vert.x is that it is a polyglot platform.  If our SPIs could be
> > written in any language and deployed easily this would be a huge win and
> > could potential bring together very diverse communities (node.js and
> > linux-python-admins).
> >
> > Something to think about for Keycloak 2.0.
> >
> > Bill
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150108/4285342c/attachment.html 

From psilva at redhat.com  Thu Jan  8 18:09:47 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 8 Jan 2015 18:09:47 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <1060798725.6380928.1420758110779.JavaMail.zimbra@redhat.com>
Message-ID: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>

Hi,

   I was wondering if we can support device registration and verification during login as follows:

       1) Users can enable/disable behavior in admin console for a specific realm.
       2) After a successful login, KC checks if the user's device is known. For instance, Browser and Operating System.
       3) If not recognized, KC shows a page asking user if he wants to enable the device.
       4) KC sends an email to user with a code.
       5) When trying to login again, user must provide the code to register the new device and get authenticated.
       6) For now on, users can authenticate without asking for permission if using the same device.

   Any thoughts ?

Regards.
Pedro Igor
    

From mposolda at redhat.com  Fri Jan  9 01:25:02 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 09 Jan 2015 07:25:02 +0100
Subject: [keycloak-dev] Keycloak in JBoss projects
In-Reply-To: <1576996562.5540472.1420712719396.JavaMail.zimbra@redhat.com>
References: <1576996562.5540472.1420712719396.JavaMail.zimbra@redhat.com>
Message-ID: <54AF743E.4040705@redhat.com>

On 8.1.2015 11:25, Stian Thorgersen wrote:
> There's a lot of JBoss projects already integrating or looking at using Keycloak:
>
> * AeroGear UPS
> * LiveOak
> * RTGov
> * Hawt.io
> * Fabric8
> * Fuse
> * S-RAMP
> * APIMan
> * ...
>
> I think now is the time to make sure we can provide the best and consistent experience for all projects. With that regards there's improvements we can make:
>
> * Embeddable Keycloak - provide a slimmed down profile of Keycloak that can easily be embedded into existing projects. The big question here is should we support deploying to other containers than WildFly? I reckon as long as projects support other projects and we want to be the main auth solution we do. I'd hate to see projects having to provide alternative mechanisms themselves to continue to support Tomcat for example
+1

I think that at least some basic support of auth-server on other 
containers would be good. For example, if I am site administrator with 
my applications running on Jetty in production, then I would look for 
SSO/OIDC solution, which would run on Jetty too. Having my apps on Jetty 
and auth-server on separate WF/EAP6 is overkill. Many tomcat/jetty/etc. 
based deployments would go for different sso than keycloak due to this imo.

Maybe it could be really some slimmed down solution, which won't support 
all the features (like CLI for example). As long as it allows add/remove 
providers and themes and configure them through keycloak-server.json, it 
should be ok imo.

As first thing, it seems that we may need osgi bundling of auth-server 
running on jetty server on fuse/karaf. Currently hawtio and fuse 
integration always requires external keycloak, which is a bit 
limiting... It's something I can look into in near future (likely after 
finish kerberos and other features with bigger priority).

Marek
> * External Keycloak - make it simpler to link a project to an external Keycloak, including sharing the master realm for SSO to all consoles
> * Configuration - for both embeddable and external we need to make it easier for projects to bootstrap and update application configuration (for example if hostname changes)
> * Unified console - we need to align better with PatternFly and RCUE. We should also provide a mechanism for linking between consoles
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Fri Jan  9 01:35:28 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 09 Jan 2015 07:35:28 +0100
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
Message-ID: <54AF76B0.5@redhat.com>

That might be nice feature. Maybe it may be also good to support 
different authentication methods depending on the device? For example 
require kerberos login when user loggs through his laptop, and password 
authentication when login through mobile phone etc.

Marek

On 9.1.2015 00:09, Pedro Igor Silva wrote:
> Hi,
>
>     I was wondering if we can support device registration and verification during login as follows:
>
>         1) Users can enable/disable behavior in admin console for a specific realm.
>         2) After a successful login, KC checks if the user's device is known. For instance, Browser and Operating System.
>         3) If not recognized, KC shows a page asking user if he wants to enable the device.
>         4) KC sends an email to user with a code.
>         5) When trying to login again, user must provide the code to register the new device and get authenticated.
>         6) For now on, users can authenticate without asking for permission if using the same device.
>
>     Any thoughts ?
>
> Regards.
> Pedro Igor
>      
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Jan  9 02:02:16 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 Jan 2015 02:02:16 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
Message-ID: <2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>

Requiring email seems unnecessary and awkward to me. The normal flow I've seen (at least on Android) is that you simply login with your username and password on the device. You can then go into your account later and list devices that are registered.

IMO we need to have a bigger discussion on how mobile and devices which includes the AeroGear guys.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 9 January, 2015 12:09:47 AM
> Subject: [keycloak-dev] Device registration and verification
> 
> Hi,
> 
>    I was wondering if we can support device registration and verification
>    during login as follows:
> 
>        1) Users can enable/disable behavior in admin console for a specific
>        realm.
>        2) After a successful login, KC checks if the user's device is known.
>        For instance, Browser and Operating System.
>        3) If not recognized, KC shows a page asking user if he wants to
>        enable the device.
>        4) KC sends an email to user with a code.
>        5) When trying to login again, user must provide the code to register
>        the new device and get authenticated.
>        6) For now on, users can authenticate without asking for permission if
>        using the same device.
> 
>    Any thoughts ?
> 
> Regards.
> Pedro Igor
>     
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From psilva at redhat.com  Fri Jan  9 06:44:20 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 9 Jan 2015 06:44:20 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>
Message-ID: <140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 9, 2015 5:02:16 AM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> Requiring email seems unnecessary and awkward to me. The normal flow I've
> seen (at least on Android) is that you simply login with your username and
> password on the device. You can then go into your account later and list
> devices that are registered.

I was thinking more about browser-based scenarios. Mobile behaves differently but similary. In any case, the idea is secure user account based on the devices he usually use to access something. If that changes, it might be a threat.

> 
> IMO we need to have a bigger discussion on how mobile and devices which
> includes the AeroGear guys.
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, 9 January, 2015 12:09:47 AM
> > Subject: [keycloak-dev] Device registration and verification
> > 
> > Hi,
> > 
> >    I was wondering if we can support device registration and verification
> >    during login as follows:
> > 
> >        1) Users can enable/disable behavior in admin console for a specific
> >        realm.
> >        2) After a successful login, KC checks if the user's device is
> >        known.
> >        For instance, Browser and Operating System.
> >        3) If not recognized, KC shows a page asking user if he wants to
> >        enable the device.
> >        4) KC sends an email to user with a code.
> >        5) When trying to login again, user must provide the code to
> >        register
> >        the new device and get authenticated.
> >        6) For now on, users can authenticate without asking for permission
> >        if
> >        using the same device.
> > 
> >    Any thoughts ?
> > 
> > Regards.
> > Pedro Igor
> >     
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From psilva at redhat.com  Fri Jan  9 06:51:05 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 9 Jan 2015 06:51:05 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54AF76B0.5@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<54AF76B0.5@redhat.com>
Message-ID: <1218982399.6503183.1420804265955.JavaMail.zimbra@redhat.com>

+1. 

Another thing to keep in mind is support for Adaptative/Multi Security Level. Wen can also define levels based on the authc mechanism, user device, network, etc.

----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Friday, January 9, 2015 4:35:28 AM
Subject: Re: [keycloak-dev] Device registration and verification

That might be nice feature. Maybe it may be also good to support 
different authentication methods depending on the device? For example 
require kerberos login when user loggs through his laptop, and password 
authentication when login through mobile phone etc.

Marek

On 9.1.2015 00:09, Pedro Igor Silva wrote:
> Hi,
>
>     I was wondering if we can support device registration and verification during login as follows:
>
>         1) Users can enable/disable behavior in admin console for a specific realm.
>         2) After a successful login, KC checks if the user's device is known. For instance, Browser and Operating System.
>         3) If not recognized, KC shows a page asking user if he wants to enable the device.
>         4) KC sends an email to user with a code.
>         5) When trying to login again, user must provide the code to register the new device and get authenticated.
>         6) For now on, users can authenticate without asking for permission if using the same device.
>
>     Any thoughts ?
>
> Regards.
> Pedro Igor
>      
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From gerbermichi at me.com  Fri Jan  9 07:45:26 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 09 Jan 2015 12:45:26 +0000 (GMT)
Subject: [keycloak-dev] Strange behaviour with invalid state param
Message-ID: <1ccbcdfa-a3e4-422e-8395-8ac2f99fec08@me.com>

Hi,

I have a strange behaviour with an invalid state param.

The server writes the following log, which is correct:
WARN ?[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-17) No state cookie

After that I receive a 400 error in my browser with the following URL:
https://pcc811.hrms.ch:9443/index.html?code=Q-NK1wwTdqja5XU8lUkNkZnEy40ZdCx2FjC6qslukdc.9ef6b6f7-b888-4a59-b34c-7af6d490614b&state=dc-4d82-b0c9-d434b917dfce

I can load this URL again and than I am successfully logged in.

Is this the correct behaviour?

Best
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150109/693c158d/attachment.html 

From stian at redhat.com  Fri Jan  9 08:29:01 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 Jan 2015 08:29:01 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>
	<140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>
Message-ID: <1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 9 January, 2015 12:44:20 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, January 9, 2015 5:02:16 AM
> > Subject: Re: [keycloak-dev] Device registration and verification
> > 
> > Requiring email seems unnecessary and awkward to me. The normal flow I've
> > seen (at least on Android) is that you simply login with your username and
> > password on the device. You can then go into your account later and list
> > devices that are registered.
> 
> I was thinking more about browser-based scenarios. Mobile behaves differently
> but similary. In any case, the idea is secure user account based on the
> devices he usually use to access something. If that changes, it might be a
> threat.

Sure, but what you're actually talking about here is using email as a 2nd factor authentication right?

My plan was that we'd have more ways to do 2nd factor auth (sms, email, google authenticator, yubikey, custom) and have an option on a realm to enable "trusted" devices. If the realm has trusted devices enabled then the user only has to use the 2nd factor authentication say every 30 days or so.

> 
> > 
> > IMO we need to have a bigger discussion on how mobile and devices which
> > includes the AeroGear guys.
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, 9 January, 2015 12:09:47 AM
> > > Subject: [keycloak-dev] Device registration and verification
> > > 
> > > Hi,
> > > 
> > >    I was wondering if we can support device registration and verification
> > >    during login as follows:
> > > 
> > >        1) Users can enable/disable behavior in admin console for a
> > >        specific
> > >        realm.
> > >        2) After a successful login, KC checks if the user's device is
> > >        known.
> > >        For instance, Browser and Operating System.
> > >        3) If not recognized, KC shows a page asking user if he wants to
> > >        enable the device.
> > >        4) KC sends an email to user with a code.
> > >        5) When trying to login again, user must provide the code to
> > >        register
> > >        the new device and get authenticated.
> > >        6) For now on, users can authenticate without asking for
> > >        permission
> > >        if
> > >        using the same device.
> > > 
> > >    Any thoughts ?
> > > 
> > > Regards.
> > > Pedro Igor
> > >     
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

From stian at redhat.com  Fri Jan  9 08:35:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 Jan 2015 08:35:31 -0500 (EST)
Subject: [keycloak-dev] Strange behaviour with invalid state param
In-Reply-To: <1ccbcdfa-a3e4-422e-8395-8ac2f99fec08@me.com>
References: <1ccbcdfa-a3e4-422e-8395-8ac2f99fec08@me.com>
Message-ID: <1117106757.6318987.1420810531868.JavaMail.zimbra@redhat.com>

Doesn't sound correct to me. Are you expecting the invalid state param result?

Is this reproducible? 

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 January, 2015 1:45:26 PM
> Subject: [keycloak-dev] Strange behaviour with invalid state param
> 
> Hi,
> 
> I have a strange behaviour with an invalid state param.
> 
> The server writes the following log, which is correct:
> WARN [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-17) No
> state cookie
> 
> After that I receive a 400 error in my browser with the following URL:
> https://pcc811.hrms.ch:9443/index.html?code=Q-NK1wwTdqja5XU8lUkNkZnEy40ZdCx2FjC6qslukdc.9ef6b6f7-b888-4a59-b34c-7af6d490614b&state=dc-4d82-b0c9-d434b917dfce
> 
> I can load this URL again and than I am successfully logged in.
> 
> Is this the correct behaviour?
> 
> Best
> Michael
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Fri Jan  9 08:40:44 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 09 Jan 2015 08:40:44 -0500
Subject: [keycloak-dev] Strange behaviour with invalid state param
In-Reply-To: <1ccbcdfa-a3e4-422e-8395-8ac2f99fec08@me.com>
References: <1ccbcdfa-a3e4-422e-8395-8ac2f99fec08@me.com>
Message-ID: <54AFDA5C.50502@redhat.com>

What I think is happening is that you have an invalid state cookie (as 
per the oauth spec), you reload the app URL again and authentication is 
successful.  While I don't know why you are getting "No state cookie" 
the rest makes sense as you're just going through a successful login.

On 1/9/2015 7:45 AM, Michael Gerber wrote:
> Hi,
>
> I have a strange behaviour with an invalid state param.
>
> The server writes the following log, which is correct:
> WARN  [org.keycloak.adapters.OAuthRequestAuthenticator] (default
> task-17) No state cookie
>
> After that I receive a 400 error in my browser with the following URL:
> https://pcc811.hrms.ch:9443/index.html?code=Q-NK1wwTdqja5XU8lUkNkZnEy40ZdCx2FjC6qslukdc.9ef6b6f7-b888-4a59-b34c-7af6d490614b&state=dc-4d82-b0c9-d434b917dfce
>
> I can load this URL again and than I am successfully logged in.
>
> Is this the correct behaviour?
>
> Best
> Michael
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From lvadali at cisco.com  Fri Jan  9 08:51:09 2015
From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali))
Date: Fri, 9 Jan 2015 13:51:09 +0000
Subject: [keycloak-dev] HA Support For Keycloak
Message-ID: <BEA822DA38EAC24E869EEB395ABFA21C0D162674@xmb-aln-x08.cisco.com>

Hi ,

Does Keycloak1.0.4_Final has HA Support? If not, then from  which release Keycloak  HA support is available?

Thanks,
Lakshmi Narayana V
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150109/212b011e/attachment-0001.html 

From stian at redhat.com  Fri Jan  9 08:54:24 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 9 Jan 2015 08:54:24 -0500 (EST)
Subject: [keycloak-dev] HA Support For Keycloak
In-Reply-To: <BEA822DA38EAC24E869EEB395ABFA21C0D162674@xmb-aln-x08.cisco.com>
References: <BEA822DA38EAC24E869EEB395ABFA21C0D162674@xmb-aln-x08.cisco.com>
Message-ID: <1407376678.6382831.1420811664930.JavaMail.zimbra@redhat.com>

Keycloak has limited HA support in 1.0.4, but this is much improved in 1.1.0.Beta2. 1.1.0.Final should be out next week. 

See http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/clustering.html for more details

----- Original Message -----
> From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 January, 2015 2:51:09 PM
> Subject: [keycloak-dev] HA Support For Keycloak
> 
> 
> 
> Hi ,
> 
> 
> 
> Does Keycloak1.0.4_Final has HA Support? If not, then from which release
> Keycloak HA support is available?
> 
> 
> 
> Thanks,
> 
> Lakshmi Narayana V
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From gerbermichi at me.com  Fri Jan  9 09:14:41 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 09 Jan 2015 14:14:41 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_Re=3A__Strange_behaviour_with_invalid_s?=
 =?utf-8?q?tate_param?=
Message-ID: <430ec458-bafb-43f4-8347-568213454398@me.com>

Someone in our company bookmarked the login URL
https://localhost:9443/auth/realms/uka/protocol/openid-connect/login?client_id=uka-solutions&redirect_uri=https%3A%2F%2Flocalhost%3A9443%2Findex.html&state=1%2Ff761c116-eef1-4744-b40d-792cd14c1386&login=true
And he reported this behaviour.

I dont understand why the login is permitted with an invalid state. I know the login was successful but the application did not request this login (state is wrong), so it should not allow it.

@stian
this behaviour is easy reproducible.
Open the customer-portal example app in a browser, copy the login url.
Close the browser and open it again and use the old url. (or clear your cookies ;-)
Remove all parameters from the url after you received the bad request error and you should get in.


Am 09. Januar 2015 um 14:41 schrieb Bill Burke <bburke at redhat.com>:

What I think is happening is that you have an invalid state cookie (as 
per the oauth spec), you reload the app URL again and authentication is 
successful. While I don't know why you are getting "No state cookie" 
the rest makes sense as you're just going through a successful login.

On 1/9/2015 7:45 AM, Michael Gerber wrote:
Hi,
I have a strange behaviour with an invalid state param.
The server writes the following log, which is correct:
WARN [org.keycloak.adapters.OAuthRequestAuthenticator] (default
task-17) No state cookie
After that I receive a 400 error in my browser with the following URL:
https://pcc811.hrms.ch:9443/index.html?code=Q-NK1wwTdqja5XU8lUkNkZnEy40ZdCx2FjC6qslukdc.9ef6b6f7-b888-4a59-b34c-7af6d490614b&state=dc-4d82-b0c9-d434b917dfce
I can load this URL again and than I am successfully logged in.
Is this the correct behaviour?
Best
Michael
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150109/321aa573/attachment.html 

From gerbermichi at me.com  Fri Jan  9 10:01:49 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 09 Jan 2015 15:01:49 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_A_disabled_user_receives_a_confusing_in?=
 =?utf-8?q?fo_message=2C_if_he_tries_to_reset_his_password?=
Message-ID: <65bdef92-6a52-43bd-9a66-ce8aa1df19e5@me.com>

A disabled user receives the following info message, if he tries to reset his password:
You should receive an email shortly with further instructions.

This is a bit confusing. A message like that would be nicer:
Failed to send email, please contact the administrator.

I will create a PR if that is ok with you?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150109/49ec99ba/attachment.html 

From psilva at redhat.com  Fri Jan  9 10:09:51 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 9 Jan 2015 10:09:51 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>
	<140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>
	<1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>
Message-ID: <482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 9, 2015 11:29:01 AM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, 9 January, 2015 12:44:20 PM
> > Subject: Re: [keycloak-dev] Device registration and verification
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, January 9, 2015 5:02:16 AM
> > > Subject: Re: [keycloak-dev] Device registration and verification
> > > 
> > > Requiring email seems unnecessary and awkward to me. The normal flow I've
> > > seen (at least on Android) is that you simply login with your username
> > > and
> > > password on the device. You can then go into your account later and list
> > > devices that are registered.
> > 
> > I was thinking more about browser-based scenarios. Mobile behaves
> > differently
> > but similary. In any case, the idea is secure user account based on the
> > devices he usually use to access something. If that changes, it might be a
> > threat.
> 
> Sure, but what you're actually talking about here is using email as a 2nd
> factor authentication right?

No. Email is not a 2nd factor authentication, but the code itself. Email is just how you send the code and also how you alert the user that someone is trying to access his account from a not recognized device. In this case, the code is just an "activation code" (not an authentication code), we can even remove the code and just provide a confirmation link, for instance.

This is not about authenticating users, but authorization. Allowing access only from devices previously approved by the user. Let's say you usually access your bank from your home computer. But for some reason, you need temporary access from a LAN house computer. You probably don't want to allow access from LAN house computers later on.

> 
> My plan was that we'd have more ways to do 2nd factor auth (sms, email,
> google authenticator, yubikey, custom) and have an option on a realm to
> enable "trusted" devices. If the realm has trusted devices enabled then the
> user only has to use the 2nd factor authentication say every 30 days or so.

What I'm proposing is another security layer, which can be used together with 2nd factor authentication.

> 
> > 
> > > 
> > > IMO we need to have a bigger discussion on how mobile and devices which
> > > includes the AeroGear guys.
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > Sent: Friday, 9 January, 2015 12:09:47 AM
> > > > Subject: [keycloak-dev] Device registration and verification
> > > > 
> > > > Hi,
> > > > 
> > > >    I was wondering if we can support device registration and
> > > >    verification
> > > >    during login as follows:
> > > > 
> > > >        1) Users can enable/disable behavior in admin console for a
> > > >        specific
> > > >        realm.
> > > >        2) After a successful login, KC checks if the user's device is
> > > >        known.
> > > >        For instance, Browser and Operating System.
> > > >        3) If not recognized, KC shows a page asking user if he wants to
> > > >        enable the device.
> > > >        4) KC sends an email to user with a code.
> > > >        5) When trying to login again, user must provide the code to
> > > >        register
> > > >        the new device and get authenticated.
> > > >        6) For now on, users can authenticate without asking for
> > > >        permission
> > > >        if
> > > >        using the same device.
> > > > 
> > > >    Any thoughts ?
> > > > 
> > > > Regards.
> > > > Pedro Igor
> > > >     
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > 
> > > 
> > 
> 

From coolmind182006 at gmail.com  Sun Jan 11 06:22:03 2015
From: coolmind182006 at gmail.com (coolmind182006 .)
Date: Sun, 11 Jan 2015 16:52:03 +0530
Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
Message-ID: <CAM7bvCQBnAabSyOPTB=F3-LhhPe1jpvNgmsezAGv4QaaNfTXQw@mail.gmail.com>

plugin name : keycloak-oauth
<https://github.com/mnadeem/jenkins-keycloak-plugin>
github account : mnadeem <https://github.com/mnadeem>
existing repository : https://github.com/mnadeem/jenkins-keycloak-plugin
wiki : https://wiki.jenkins-ci.org/display/JENKINS/keycloak-oauth-plugin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150111/daf01c5c/attachment.html 

From stian at redhat.com  Mon Jan 12 02:01:35 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 02:01:35 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>
	<140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>
	<1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
Message-ID: <1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 9 January, 2015 4:09:51 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, January 9, 2015 11:29:01 AM
> > Subject: Re: [keycloak-dev] Device registration and verification
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, 9 January, 2015 12:44:20 PM
> > > Subject: Re: [keycloak-dev] Device registration and verification
> > > 
> > > ----- Original Message -----
> > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > Sent: Friday, January 9, 2015 5:02:16 AM
> > > > Subject: Re: [keycloak-dev] Device registration and verification
> > > > 
> > > > Requiring email seems unnecessary and awkward to me. The normal flow
> > > > I've
> > > > seen (at least on Android) is that you simply login with your username
> > > > and
> > > > password on the device. You can then go into your account later and
> > > > list
> > > > devices that are registered.
> > > 
> > > I was thinking more about browser-based scenarios. Mobile behaves
> > > differently
> > > but similary. In any case, the idea is secure user account based on the
> > > devices he usually use to access something. If that changes, it might be
> > > a
> > > threat.
> > 
> > Sure, but what you're actually talking about here is using email as a 2nd
> > factor authentication right?
> 
> No. Email is not a 2nd factor authentication, but the code itself. Email is
> just how you send the code and also how you alert the user that someone is
> trying to access his account from a not recognized device. In this case, the
> code is just an "activation code" (not an authentication code), we can even
> remove the code and just provide a confirmation link, for instance.
> 
> This is not about authenticating users, but authorization. Allowing access
> only from devices previously approved by the user. Let's say you usually
> access your bank from your home computer. But for some reason, you need
> temporary access from a LAN house computer. You probably don't want to allow
> access from LAN house computers later on.
> 
> > 
> > My plan was that we'd have more ways to do 2nd factor auth (sms, email,
> > google authenticator, yubikey, custom) and have an option on a realm to
> > enable "trusted" devices. If the realm has trusted devices enabled then the
> > user only has to use the 2nd factor authentication say every 30 days or so.
> 
> What I'm proposing is another security layer, which can be used together with
> 2nd factor authentication.

I see no difference, except for implementation details

> 
> > 
> > > 
> > > > 
> > > > IMO we need to have a bigger discussion on how mobile and devices which
> > > > includes the AeroGear guys.
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > > Sent: Friday, 9 January, 2015 12:09:47 AM
> > > > > Subject: [keycloak-dev] Device registration and verification
> > > > > 
> > > > > Hi,
> > > > > 
> > > > >    I was wondering if we can support device registration and
> > > > >    verification
> > > > >    during login as follows:
> > > > > 
> > > > >        1) Users can enable/disable behavior in admin console for a
> > > > >        specific
> > > > >        realm.
> > > > >        2) After a successful login, KC checks if the user's device is
> > > > >        known.
> > > > >        For instance, Browser and Operating System.
> > > > >        3) If not recognized, KC shows a page asking user if he wants
> > > > >        to
> > > > >        enable the device.
> > > > >        4) KC sends an email to user with a code.
> > > > >        5) When trying to login again, user must provide the code to
> > > > >        register
> > > > >        the new device and get authenticated.
> > > > >        6) For now on, users can authenticate without asking for
> > > > >        permission
> > > > >        if
> > > > >        using the same device.
> > > > > 
> > > > >    Any thoughts ?
> > > > > 
> > > > > Regards.
> > > > > Pedro Igor
> > > > >     
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > 
> > > > 
> > > 
> > 
> 

From stian at redhat.com  Mon Jan 12 02:40:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 02:40:07 -0500 (EST)
Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
In-Reply-To: <CAM7bvCQBnAabSyOPTB=F3-LhhPe1jpvNgmsezAGv4QaaNfTXQw@mail.gmail.com>
References: <CAM7bvCQBnAabSyOPTB=F3-LhhPe1jpvNgmsezAGv4QaaNfTXQw@mail.gmail.com>
Message-ID: <977292214.7534857.1421048407668.JavaMail.zimbra@redhat.com>

Awesome, we'd love to pull this in to our GitHub

----- Original Message -----
> From: "coolmind182006 ." <coolmind182006 at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, 11 January, 2015 12:22:03 PM
> Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
> 
> 
> plugin name : keycloak-oauth
> github account : mnadeem
> existing repository : https://github.com/mnadeem/jenkins-keycloak-plugin
> wiki : https://wiki.jenkins-ci.org/display/JENKINS/keycloak-oauth-plugin
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Mon Jan 12 04:33:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 04:33:54 -0500 (EST)
Subject: [keycloak-dev] Master bumped to 1.2.0.Beta1-SNAPSHOT
In-Reply-To: <1031546796.7770402.1421055102953.JavaMail.zimbra@redhat.com>
Message-ID: <2128675899.7778540.1421055234283.JavaMail.zimbra@redhat.com>

I created 1.1.x branch for 1.1.0.Final release and bumped master to 1.2.0.Beta1-SNAPSHOT

So go ahead and start work on 1.2 features :)

There's still some issues left to do for 1.1.0.Final, which me and Marek will sort out. I'm aiming to release in a few days. If there's anything you'd like to add to 1.1.0-Final please let me know in advance.

From stian at redhat.com  Mon Jan 12 04:45:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 04:45:49 -0500 (EST)
Subject: [keycloak-dev] A disabled user receives a confusing info
 message, if he tries to reset his password
In-Reply-To: <65bdef92-6a52-43bd-9a66-ce8aa1df19e5@me.com>
References: <65bdef92-6a52-43bd-9a66-ce8aa1df19e5@me.com>
Message-ID: <503310617.7831412.1421055949012.JavaMail.zimbra@redhat.com>

This is intentional. If we provide specific error messages on reset password it can be used to find out whether or not a username/email is valid. Same applies to login, instead of saying invalid username it just says invalid username or password.

As an improvement we could extend the message to say if you haven't received a message within a certain time, then retry or contact an admin/support.

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 January, 2015 4:01:49 PM
> Subject: [keycloak-dev]  A disabled user receives a confusing info message, if he tries to reset his password
> 
> A disabled user receives the following info message, if he tries to reset his
> password:
> You should receive an email shortly with further instructions.
> 
> This is a bit confusing. A message like that would be nicer:
> Failed to send email, please contact the administrator.
> 
> I will create a PR if that is ok with you?
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Mon Jan 12 04:54:18 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 04:54:18 -0500 (EST)
Subject: [keycloak-dev] Strange behaviour with invalid state param
In-Reply-To: <430ec458-bafb-43f4-8347-568213454398@me.com>
References: <430ec458-bafb-43f4-8347-568213454398@me.com>
Message-ID: <1736077571.7903251.1421056458262.JavaMail.zimbra@redhat.com>

This is actually expected behaviour. What happens is:

1. Copy/paste the login URL with the invalid state
2. Login to the SSO realm
3. Redirect back to the app which throws error due to invalid state
4. Now you're not logged-in to the application, but your logged in to the SSO realm
5. Remove the code param from the link which causes another redirect to login
6. As you're already logged in to the SSO realm you're immediately redirected back to the app with a new code and state param


----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 January, 2015 3:14:41 PM
> Subject: [keycloak-dev]  Re:  Strange behaviour with invalid state param
> 
> Someone in our company bookmarked the login URL
> https://localhost:9443/auth/realms/uka/protocol/openid-connect/login?client_id=uka-solutions&redirect_uri=https%3A%2F%2Flocalhost%3A9443%2Findex.html&state=1%2Ff761c116-eef1-4744-b40d-792cd14c1386&login=true
> And he reported this behaviour.
> 
> I dont understand why the login is permitted with an invalid state. I know
> the login was successful but the application did not request this login
> (state is wrong), so it should not allow it.
> 
> @stian
> this behaviour is easy reproducible.
> Open the customer-portal example app in a browser, copy the login url.
> Close the browser and open it again and use the old url. (or clear your
> cookies ;-)
> Remove all parameters from the url after you received the bad request error
> and you should get in.
> 
> 
> Am 09. Januar 2015 um 14:41 schrieb Bill Burke <bburke at redhat.com>:
> 
> 
> 
> 
> What I think is happening is that you have an invalid state cookie (as
> per the oauth spec), you reload the app URL again and authentication is
> successful. While I don't know why you are getting "No state cookie"
> the rest makes sense as you're just going through a successful login.
> 
> On 1/9/2015 7:45 AM, Michael Gerber wrote:
> 
> 
> Hi,
> 
> 
> 
> I have a strange behaviour with an invalid state param.
> 
> 
> 
> The server writes the following log, which is correct:
> 
> WARN [org.keycloak.adapters.OAuthRequestAuthenticator] (default
> 
> task-17) No state cookie
> 
> 
> 
> After that I receive a 400 error in my browser with the following URL:
> 
> https://pcc811.hrms.ch:9443/index.html?code=Q-NK1wwTdqja5XU8lUkNkZnEy40ZdCx2FjC6qslukdc.9ef6b6f7-b888-4a59-b34c-7af6d490614b&state=dc-4d82-b0c9-d434b917dfce
> 
> 
> 
> I can load this URL again and than I am successfully logged in.
> 
> 
> 
> Is this the correct behaviour?
> 
> 
> 
> Best
> 
> Michael
> 
> 
> 
> 
> 
> _______________________________________________
> 
> keycloak-dev mailing list
> 
> keycloak-dev at lists.jboss.org
> 
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From gerbermichi at me.com  Mon Jan 12 05:20:02 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 12 Jan 2015 10:20:02 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_Re=3A___A_disabled_user_receives_a_conf?=
 =?utf-8?q?using_info_message=2C_if_he_tries_to_reset_his_password?=
Message-ID: <4ba0126a-5594-47f7-9354-cafdb31fa0ef@me.com>

Thank you, that sounds logical.

I just wondered, because you have a different error message for disabled users on the login screen.
"Account is disabled, contact admin"

Best
Michael

Am 12. Januar 2015 um 10:45 schrieb Stian Thorgersen <stian at redhat.com>:

This is intentional. If we provide specific error messages on reset password it can be used to find out whether or not a username/email is valid. Same applies to login, instead of saying invalid username it just says invalid username or password.

As an improvement we could extend the message to say if you haven't received a message within a certain time, then retry or contact an admin/support.

----- Original Message -----
From: "Michael Gerber" <gerbermichi at me.com>
To: keycloak-dev at lists.jboss.org
Sent: Friday, 9 January, 2015 4:01:49 PM
Subject: [keycloak-dev] A disabled user receives a confusing info message, if he tries to reset his password
A disabled user receives the following info message, if he tries to reset his
password:
You should receive an email shortly with further instructions.
This is a bit confusing. A message like that would be nicer:
Failed to send email, please contact the administrator.
I will create a PR if that is ok with 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/20150112/a2ba4cb6/attachment.html 

From stian at redhat.com  Mon Jan 12 06:25:12 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 06:25:12 -0500 (EST)
Subject: [keycloak-dev] A disabled user receives a confusing info
 message, if he tries to reset his password
In-Reply-To: <4ba0126a-5594-47f7-9354-cafdb31fa0ef@me.com>
References: <4ba0126a-5594-47f7-9354-cafdb31fa0ef@me.com>
Message-ID: <258178042.8121119.1421061912520.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 January, 2015 11:20:02 AM
> Subject: Re: [keycloak-dev]  A disabled user receives a confusing info message, if he tries to reset his password
> 
> Thank you, that sounds logical.
> 
> I just wondered, because you have a different error message for disabled
> users on the login screen.
> "Account is disabled, contact admin"

That should only be shown after a user has logged in with valid username/password, if you try to login with an invalid password and disabled user it should show invalid username/password.

> 
> Best
> Michael
> 
> Am 12. Januar 2015 um 10:45 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> This is intentional. If we provide specific error messages on reset password
> it can be used to find out whether or not a username/email is valid. Same
> applies to login, instead of saying invalid username it just says invalid
> username or password.
> 
> As an improvement we could extend the message to say if you haven't received
> a message within a certain time, then retry or contact an admin/support.
> 
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 January, 2015 4:01:49 PM
> Subject: [keycloak-dev] A disabled user receives a confusing info message, if
> he tries to reset his password
> A disabled user receives the following info message, if he tries to reset his
> password:
> You should receive an email shortly with further instructions.
> This is a bit confusing. A message like that would be nicer:
> Failed to send email, please contact the administrator.
> I will create a PR if that is ok with you?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From gerbermichi at me.com  Mon Jan 12 07:30:46 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 12 Jan 2015 12:30:46 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_Re=3A___A_disabled_user_receives_a_conf?=
 =?utf-8?q?using_info_message=2C_if_he_tries_to_reset_his_password?=
Message-ID: <45b1e552-3823-4ec1-be85-a78138eddf66@me.com>

Unfortunately, it isn't implemented like that.

Have a look at the authenticateInternal method of the AuthenticationManager class.
AuthenticationStatus.ACCOUNT_DISABLED;
is returned?before?the?validCredentials method is invoked.

Best
Michael

Am 12. Januar 2015 um 12:25 schrieb Stian Thorgersen <stian at redhat.com>:



----- Original Message -----
From: "Michael Gerber" <gerbermichi at me.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Monday, 12 January, 2015 11:20:02 AM
Subject: Re: [keycloak-dev] A disabled user receives a confusing info message, if he tries to reset his password
Thank you, that sounds logical.
I just wondered, because you have a different error message for disabled
users on the login screen.
"Account is disabled, contact admin"

That should only be shown after a user has logged in with valid username/password, if you try to login with an invalid password and disabled user it should show invalid username/password.

Best
Michael
Am 12. Januar 2015 um 10:45 schrieb Stian Thorgersen <stian at redhat.com>:
This is intentional. If we provide specific error messages on reset password
it can be used to find out whether or not a username/email is valid. Same
applies to login, instead of saying invalid username it just says invalid
username or password.
As an improvement we could extend the message to say if you haven't received
a message within a certain time, then retry or contact an admin/support.
----- Original Message -----
From: "Michael Gerber" <gerbermichi at me.com>
To: keycloak-dev at lists.jboss.org
Sent: Friday, 9 January, 2015 4:01:49 PM
Subject: [keycloak-dev] A disabled user receives a confusing info message, if
he tries to reset his password
A disabled user receives the following info message, if he tries to reset his
password:
You should receive an email shortly with further instructions.
This is a bit confusing. A message like that would be nicer:
Failed to send email, please contact the administrator.
I will create a PR if that is ok with 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/20150112/77668503/attachment-0001.html 

From stian at redhat.com  Mon Jan 12 07:34:20 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 07:34:20 -0500 (EST)
Subject: [keycloak-dev] A disabled user receives a confusing info
 message, if he tries to reset his password
In-Reply-To: <45b1e552-3823-4ec1-be85-a78138eddf66@me.com>
References: <45b1e552-3823-4ec1-be85-a78138eddf66@me.com>
Message-ID: <1554604279.8202237.1421066060668.JavaMail.zimbra@redhat.com>

That's incorrect, can you create a jira please?

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 January, 2015 1:30:46 PM
> Subject: Re: [keycloak-dev]  A disabled user receives a confusing info message, if he tries to reset his password
> 
> Unfortunately, it isn't implemented like that.
> 
> Have a look at the authenticateInternal method of the AuthenticationManager
> class.
> AuthenticationStatus.ACCOUNT_DISABLED;
> is returned?before?the?validCredentials method is invoked.
> 
> Best
> Michael
> 
> Am 12. Januar 2015 um 12:25 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> 
> 
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 January, 2015 11:20:02 AM
> Subject: Re: [keycloak-dev] A disabled user receives a confusing info
> message, if he tries to reset his password
> Thank you, that sounds logical.
> I just wondered, because you have a different error message for disabled
> users on the login screen.
> "Account is disabled, contact admin"
> 
> That should only be shown after a user has logged in with valid
> username/password, if you try to login with an invalid password and disabled
> user it should show invalid username/password.
> 
> Best
> Michael
> Am 12. Januar 2015 um 10:45 schrieb Stian Thorgersen <stian at redhat.com>:
> This is intentional. If we provide specific error messages on reset password
> it can be used to find out whether or not a username/email is valid. Same
> applies to login, instead of saying invalid username it just says invalid
> username or password.
> As an improvement we could extend the message to say if you haven't received
> a message within a certain time, then retry or contact an admin/support.
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 9 January, 2015 4:01:49 PM
> Subject: [keycloak-dev] A disabled user receives a confusing info message, if
> he tries to reset his password
> A disabled user receives the following info message, if he tries to reset his
> password:
> You should receive an email shortly with further instructions.
> This is a bit confusing. A message like that would be nicer:
> Failed to send email, please contact the administrator.
> I will create a PR if that is ok with you?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Mon Jan 12 08:49:05 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Jan 2015 08:49:05 -0500
Subject: [keycloak-dev] Strange behaviour with invalid state param
In-Reply-To: <430ec458-bafb-43f4-8347-568213454398@me.com>
References: <430ec458-bafb-43f4-8347-568213454398@me.com>
Message-ID: <54B3D0D1.5090807@redhat.com>

Is this correct flow?

1. You visit the URL
2. You log in
3. Keycloak sets in auth server cookie so you don't have to log in again
4. Keycloak redirects back to app
5. App checks state param vs. state cookie, fails
6. Human refreshes the bad request URL after removing some parameters
7. App redirects to Keycloak to start the Open ID Connect flow
8. keycloak checks cookie, the user is already logged in and redirects 
back to app
9. You are logged in

Steps 6-9 are just normal Open ID Connect.

On 1/9/2015 9:14 AM, Michael Gerber wrote:
> Someone in our company bookmarked the login URL
> https://localhost:9443/auth/realms/uka/protocol/openid-connect/login?client_id=uka-solutions&redirect_uri=https%3A%2F%2Flocalhost%3A9443%2Findex.html&state=1%2Ff761c116-eef1-4744-b40d-792cd14c1386&login=true
> And he reported this behaviour.
>
> I dont understand why the login is permitted with an invalid state. I
> know the login was successful but the application did not request this
> login (state is wrong), so it should not allow it.
>
> @stian
> this behaviour is easy reproducible.
> Open the customer-portal example app in a browser, copy the login url.
> Close the browser and open it again and use the old url. (or clear your
> cookies ;-)
> Remove all parameters from the url after you received the bad request
> error and you should get in.
>
>
> Am 09. Januar 2015 um 14:41 schrieb Bill Burke <bburke at redhat.com>:
>
>> What I think is happening is that you have an invalid state cookie (as
>> per the oauth spec), you reload the app URL again and authentication is
>> successful. While I don't know why you are getting "No state cookie"
>> the rest makes sense as you're just going through a successful login.
>>
>> On 1/9/2015 7:45 AM, Michael Gerber wrote:
>>> Hi,
>>> I have a strange behaviour with an invalid state param.
>>> The server writes the following log, which is correct:
>>> WARN [org.keycloak.adapters.OAuthRequestAuthenticator] (default
>>> task-17) No state cookie
>>> After that I receive a 400 error in my browser with the following URL:
>>> https://pcc811.hrms.ch:9443/index.html?code=Q-NK1wwTdqja5XU8lUkNkZnEy40ZdCx2FjC6qslukdc.9ef6b6f7-b888-4a59-b34c-7af6d490614b&state=dc-4d82-b0c9-d434b917dfce
>>> I can load this URL again and than I am successfully logged in.
>>> Is this the correct behaviour?
>>> Best
>>> Michael
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> --
>> 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

From stian at redhat.com  Mon Jan 12 08:52:16 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 08:52:16 -0500 (EST)
Subject: [keycloak-dev] Poll - should we replace the Keycloak logo?
In-Reply-To: <1653410248.8269420.1421070667540.JavaMail.zimbra@redhat.com>
Message-ID: <1421216313.8270401.1421070736979.JavaMail.zimbra@redhat.com>

If we want to replace the Keycloak logo we can get the jboss.org design team to come up with one for us. This doesn't guarantee that we'll get anything better than we already have, but in that case we'll just stick with what we got.

So! Do we want a new one or not? Please vote https://doodle.com/vqqtfi3gvrkmsy48



From bburke at redhat.com  Mon Jan 12 08:56:49 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Jan 2015 08:56:49 -0500
Subject: [keycloak-dev] Poll - should we replace the Keycloak logo?
In-Reply-To: <1421216313.8270401.1421070736979.JavaMail.zimbra@redhat.com>
References: <1421216313.8270401.1421070736979.JavaMail.zimbra@redhat.com>
Message-ID: <54B3D2A1.3050508@redhat.com>

YOu know my opinion.  I hate logos with a cartoon character.  I was 
outvoted though when we first did things...

BTW, we have premade alternatives that Gabriel did.  That is an option too.

On 1/12/2015 8:52 AM, Stian Thorgersen wrote:
> If we want to replace the Keycloak logo we can get the jboss.org design team to come up with one for us. This doesn't guarantee that we'll get anything better than we already have, but in that case we'll just stick with what we got.
>
> So! Do we want a new one or not? Please vote https://doodle.com/vqqtfi3gvrkmsy48
>
>

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

From stian at redhat.com  Mon Jan 12 09:01:14 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 09:01:14 -0500 (EST)
Subject: [keycloak-dev] Poll - should we replace the Keycloak logo?
In-Reply-To: <54B3D2A1.3050508@redhat.com>
References: <1421216313.8270401.1421070736979.JavaMail.zimbra@redhat.com>
	<54B3D2A1.3050508@redhat.com>
Message-ID: <312166943.8277876.1421071274320.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>, mw-security-core at redhat.com
> Sent: Monday, 12 January, 2015 2:56:49 PM
> Subject: Re: Poll - should we replace the Keycloak logo?
> 
> YOu know my opinion.  I hate logos with a cartoon character.  I was
> outvoted though when we first did things...
> 
> BTW, we have premade alternatives that Gabriel did.  That is an option too.

Do you have them?

> 
> On 1/12/2015 8:52 AM, Stian Thorgersen wrote:
> > If we want to replace the Keycloak logo we can get the jboss.org design
> > team to come up with one for us. This doesn't guarantee that we'll get
> > anything better than we already have, but in that case we'll just stick
> > with what we got.
> >
> > So! Do we want a new one or not? Please vote
> > https://doodle.com/vqqtfi3gvrkmsy48
> >
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> 

From psilva at redhat.com  Mon Jan 12 10:06:23 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 12 Jan 2015 10:06:23 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>
	<140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>
	<1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
Message-ID: <1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, January 12, 2015 5:01:35 AM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, 9 January, 2015 4:09:51 PM
> > Subject: Re: [keycloak-dev] Device registration and verification
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, January 9, 2015 11:29:01 AM
> > > Subject: Re: [keycloak-dev] Device registration and verification
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > Sent: Friday, 9 January, 2015 12:44:20 PM
> > > > Subject: Re: [keycloak-dev] Device registration and verification
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > > Sent: Friday, January 9, 2015 5:02:16 AM
> > > > > Subject: Re: [keycloak-dev] Device registration and verification
> > > > > 
> > > > > Requiring email seems unnecessary and awkward to me. The normal flow
> > > > > I've
> > > > > seen (at least on Android) is that you simply login with your
> > > > > username
> > > > > and
> > > > > password on the device. You can then go into your account later and
> > > > > list
> > > > > devices that are registered.
> > > > 
> > > > I was thinking more about browser-based scenarios. Mobile behaves
> > > > differently
> > > > but similary. In any case, the idea is secure user account based on the
> > > > devices he usually use to access something. If that changes, it might
> > > > be
> > > > a
> > > > threat.
> > > 
> > > Sure, but what you're actually talking about here is using email as a 2nd
> > > factor authentication right?
> > 
> > No. Email is not a 2nd factor authentication, but the code itself. Email is
> > just how you send the code and also how you alert the user that someone is
> > trying to access his account from a not recognized device. In this case,
> > the
> > code is just an "activation code" (not an authentication code), we can even
> > remove the code and just provide a confirmation link, for instance.
> > 
> > This is not about authenticating users, but authorization. Allowing access
> > only from devices previously approved by the user. Let's say you usually
> > access your bank from your home computer. But for some reason, you need
> > temporary access from a LAN house computer. You probably don't want to
> > allow
> > access from LAN house computers later on.
> > 
> > > 
> > > My plan was that we'd have more ways to do 2nd factor auth (sms, email,
> > > google authenticator, yubikey, custom) and have an option on a realm to
> > > enable "trusted" devices. If the realm has trusted devices enabled then
> > > the
> > > user only has to use the 2nd factor authentication say every 30 days or
> > > so.
> > 
> > What I'm proposing is another security layer, which can be used together
> > with
> > 2nd factor authentication.
> 
> I see no difference, except for implementation details

There is a difference. Usually you see this feature in bank sites. Or even in SalesForce if you try it out. It helps providers to increase security by allowing access only from devices authorized by the user. You can even not use 2nd factor authentication at all.

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > IMO we need to have a bigger discussion on how mobile and devices
> > > > > which
> > > > > includes the AeroGear guys.
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > > > > Sent: Friday, 9 January, 2015 12:09:47 AM
> > > > > > Subject: [keycloak-dev] Device registration and verification
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > >    I was wondering if we can support device registration and
> > > > > >    verification
> > > > > >    during login as follows:
> > > > > > 
> > > > > >        1) Users can enable/disable behavior in admin console for a
> > > > > >        specific
> > > > > >        realm.
> > > > > >        2) After a successful login, KC checks if the user's device
> > > > > >        is
> > > > > >        known.
> > > > > >        For instance, Browser and Operating System.
> > > > > >        3) If not recognized, KC shows a page asking user if he
> > > > > >        wants
> > > > > >        to
> > > > > >        enable the device.
> > > > > >        4) KC sends an email to user with a code.
> > > > > >        5) When trying to login again, user must provide the code to
> > > > > >        register
> > > > > >        the new device and get authenticated.
> > > > > >        6) For now on, users can authenticate without asking for
> > > > > >        permission
> > > > > >        if
> > > > > >        using the same device.
> > > > > > 
> > > > > >    Any thoughts ?
> > > > > > 
> > > > > > Regards.
> > > > > > Pedro Igor
> > > > > >     
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

From bburke at redhat.com  Mon Jan 12 10:39:35 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Jan 2015 10:39:35 -0500
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>	<2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>	<140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>	<1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
Message-ID: <54B3EAB7.1020801@redhat.com>



On 1/12/2015 10:06 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Monday, January 12, 2015 5:01:35 AM
>> Subject: Re: [keycloak-dev] Device registration and verification
>>
>>
>>
>> ----- Original Message -----
>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Friday, 9 January, 2015 4:09:51 PM
>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Friday, January 9, 2015 11:29:01 AM
>>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Friday, 9 January, 2015 12:44:20 PM
>>>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Friday, January 9, 2015 5:02:16 AM
>>>>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>>>>
>>>>>> Requiring email seems unnecessary and awkward to me. The normal flow
>>>>>> I've
>>>>>> seen (at least on Android) is that you simply login with your
>>>>>> username
>>>>>> and
>>>>>> password on the device. You can then go into your account later and
>>>>>> list
>>>>>> devices that are registered.
>>>>>
>>>>> I was thinking more about browser-based scenarios. Mobile behaves
>>>>> differently
>>>>> but similary. In any case, the idea is secure user account based on the
>>>>> devices he usually use to access something. If that changes, it might
>>>>> be
>>>>> a
>>>>> threat.
>>>>
>>>> Sure, but what you're actually talking about here is using email as a 2nd
>>>> factor authentication right?
>>>
>>> No. Email is not a 2nd factor authentication, but the code itself. Email is
>>> just how you send the code and also how you alert the user that someone is
>>> trying to access his account from a not recognized device. In this case,
>>> the
>>> code is just an "activation code" (not an authentication code), we can even
>>> remove the code and just provide a confirmation link, for instance.
>>>
>>> This is not about authenticating users, but authorization. Allowing access
>>> only from devices previously approved by the user. Let's say you usually
>>> access your bank from your home computer. But for some reason, you need
>>> temporary access from a LAN house computer. You probably don't want to
>>> allow
>>> access from LAN house computers later on.
>>>
>>>>
>>>> My plan was that we'd have more ways to do 2nd factor auth (sms, email,
>>>> google authenticator, yubikey, custom) and have an option on a realm to
>>>> enable "trusted" devices. If the realm has trusted devices enabled then
>>>> the
>>>> user only has to use the 2nd factor authentication say every 30 days or
>>>> so.
>>>
>>> What I'm proposing is another security layer, which can be used together
>>> with
>>> 2nd factor authentication.
>>
>> I see no difference, except for implementation details
>
> There is a difference. Usually you see this feature in bank sites. Or even in SalesForce if you try it out. It helps providers to increase security by allowing access only from devices authorized by the user. You can even not use 2nd factor authentication at all.
>

How is this different than a "remember me" button?

Bill

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

From bburke at redhat.com  Mon Jan 12 10:40:50 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Jan 2015 10:40:50 -0500
Subject: [keycloak-dev] release very soon?
Message-ID: <54B3EB02.5@redhat.com>

Are we gonna release very soon?  I'm nervous about conflicting with 
Pedro's work and want 1.1 released so I can start on new stuff.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Mon Jan 12 10:56:49 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 12 Jan 2015 10:56:49 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54B3EAB7.1020801@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>
	<140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>
	<1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
Message-ID: <1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, January 12, 2015 1:39:35 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> 
> 
> On 1/12/2015 10:06 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Monday, January 12, 2015 5:01:35 AM
> >> Subject: Re: [keycloak-dev] Device registration and verification
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>> To: "Stian Thorgersen" <stian at redhat.com>
> >>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>> Sent: Friday, 9 January, 2015 4:09:51 PM
> >>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>
> >>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Friday, January 9, 2015 11:29:01 AM
> >>>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>> Sent: Friday, 9 January, 2015 12:44:20 PM
> >>>>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>>> Sent: Friday, January 9, 2015 5:02:16 AM
> >>>>>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>>>>
> >>>>>> Requiring email seems unnecessary and awkward to me. The normal flow
> >>>>>> I've
> >>>>>> seen (at least on Android) is that you simply login with your
> >>>>>> username
> >>>>>> and
> >>>>>> password on the device. You can then go into your account later and
> >>>>>> list
> >>>>>> devices that are registered.
> >>>>>
> >>>>> I was thinking more about browser-based scenarios. Mobile behaves
> >>>>> differently
> >>>>> but similary. In any case, the idea is secure user account based on the
> >>>>> devices he usually use to access something. If that changes, it might
> >>>>> be
> >>>>> a
> >>>>> threat.
> >>>>
> >>>> Sure, but what you're actually talking about here is using email as a
> >>>> 2nd
> >>>> factor authentication right?
> >>>
> >>> No. Email is not a 2nd factor authentication, but the code itself. Email
> >>> is
> >>> just how you send the code and also how you alert the user that someone
> >>> is
> >>> trying to access his account from a not recognized device. In this case,
> >>> the
> >>> code is just an "activation code" (not an authentication code), we can
> >>> even
> >>> remove the code and just provide a confirmation link, for instance.
> >>>
> >>> This is not about authenticating users, but authorization. Allowing
> >>> access
> >>> only from devices previously approved by the user. Let's say you usually
> >>> access your bank from your home computer. But for some reason, you need
> >>> temporary access from a LAN house computer. You probably don't want to
> >>> allow
> >>> access from LAN house computers later on.
> >>>
> >>>>
> >>>> My plan was that we'd have more ways to do 2nd factor auth (sms, email,
> >>>> google authenticator, yubikey, custom) and have an option on a realm to
> >>>> enable "trusted" devices. If the realm has trusted devices enabled then
> >>>> the
> >>>> user only has to use the 2nd factor authentication say every 30 days or
> >>>> so.
> >>>
> >>> What I'm proposing is another security layer, which can be used together
> >>> with
> >>> 2nd factor authentication.
> >>
> >> I see no difference, except for implementation details
> >
> > There is a difference. Usually you see this feature in bank sites. Or even
> > in SalesForce if you try it out. It helps providers to increase security
> > by allowing access only from devices authorized by the user. You can even
> > not use 2nd factor authentication at all.
> >
> 
> How is this different than a "remember me" button?

"Remember me" will allow you to get authenticated. But if you provided only temporary access from that device, you will not be able to proceed even with "remember me" checked. However, if that device was approved for you and marked as "trusted" you will be fine.

This is not about authentication, but authorization ....

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

From psilva at redhat.com  Mon Jan 12 11:04:15 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 12 Jan 2015 11:04:15 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>
	<1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
Message-ID: <778111417.7516920.1421078655343.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, January 12, 2015 1:56:49 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Monday, January 12, 2015 1:39:35 PM
> > Subject: Re: [keycloak-dev] Device registration and verification
> > 
> > 
> > 
> > On 1/12/2015 10:06 AM, Pedro Igor Silva wrote:
> > > ----- Original Message -----
> > >> From: "Stian Thorgersen" <stian at redhat.com>
> > >> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >> Sent: Monday, January 12, 2015 5:01:35 AM
> > >> Subject: Re: [keycloak-dev] Device registration and verification
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > >>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>> Sent: Friday, 9 January, 2015 4:09:51 PM
> > >>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Stian Thorgersen" <stian at redhat.com>
> > >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>>> Sent: Friday, January 9, 2015 11:29:01 AM
> > >>>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>>
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>>>> Sent: Friday, 9 January, 2015 12:44:20 PM
> > >>>>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> > >>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>>>>> Sent: Friday, January 9, 2015 5:02:16 AM
> > >>>>>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>>>>
> > >>>>>> Requiring email seems unnecessary and awkward to me. The normal flow
> > >>>>>> I've
> > >>>>>> seen (at least on Android) is that you simply login with your
> > >>>>>> username
> > >>>>>> and
> > >>>>>> password on the device. You can then go into your account later and
> > >>>>>> list
> > >>>>>> devices that are registered.
> > >>>>>
> > >>>>> I was thinking more about browser-based scenarios. Mobile behaves
> > >>>>> differently
> > >>>>> but similary. In any case, the idea is secure user account based on
> > >>>>> the
> > >>>>> devices he usually use to access something. If that changes, it might
> > >>>>> be
> > >>>>> a
> > >>>>> threat.
> > >>>>
> > >>>> Sure, but what you're actually talking about here is using email as a
> > >>>> 2nd
> > >>>> factor authentication right?
> > >>>
> > >>> No. Email is not a 2nd factor authentication, but the code itself.
> > >>> Email
> > >>> is
> > >>> just how you send the code and also how you alert the user that someone
> > >>> is
> > >>> trying to access his account from a not recognized device. In this
> > >>> case,
> > >>> the
> > >>> code is just an "activation code" (not an authentication code), we can
> > >>> even
> > >>> remove the code and just provide a confirmation link, for instance.
> > >>>
> > >>> This is not about authenticating users, but authorization. Allowing
> > >>> access
> > >>> only from devices previously approved by the user. Let's say you
> > >>> usually
> > >>> access your bank from your home computer. But for some reason, you need
> > >>> temporary access from a LAN house computer. You probably don't want to
> > >>> allow
> > >>> access from LAN house computers later on.
> > >>>
> > >>>>
> > >>>> My plan was that we'd have more ways to do 2nd factor auth (sms,
> > >>>> email,
> > >>>> google authenticator, yubikey, custom) and have an option on a realm
> > >>>> to
> > >>>> enable "trusted" devices. If the realm has trusted devices enabled
> > >>>> then
> > >>>> the
> > >>>> user only has to use the 2nd factor authentication say every 30 days
> > >>>> or
> > >>>> so.
> > >>>
> > >>> What I'm proposing is another security layer, which can be used
> > >>> together
> > >>> with
> > >>> 2nd factor authentication.
> > >>
> > >> I see no difference, except for implementation details
> > >
> > > There is a difference. Usually you see this feature in bank sites. Or
> > > even
> > > in SalesForce if you try it out. It helps providers to increase security
> > > by allowing access only from devices authorized by the user. You can even
> > > not use 2nd factor authentication at all.
> > >
> > 
> > How is this different than a "remember me" button?
> 
> "Remember me" will allow you to get authenticated. But if you provided only
> temporary access from that device, you will not be able to proceed even with
> "remember me" checked. However, if that device was approved for you and
> marked as "trusted" you will be fine.
> 
> This is not about authentication, but authorization ....

Which can be also combined with IP-based restrictions.

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

From bburke at redhat.com  Mon Jan 12 12:32:49 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Jan 2015 12:32:49 -0500
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<2064175150.6076261.1420786936364.JavaMail.zimbra@redhat.com>
	<140264251.6500859.1420803860835.JavaMail.zimbra@redhat.com>
	<1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
Message-ID: <54B40541.80507@redhat.com>



On 1/12/2015 10:56 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, January 12, 2015 1:39:35 PM
>> Subject: Re: [keycloak-dev] Device registration and verification
>>
>>
>>
>> On 1/12/2015 10:06 AM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Monday, January 12, 2015 5:01:35 AM
>>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Friday, 9 January, 2015 4:09:51 PM
>>>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Friday, January 9, 2015 11:29:01 AM
>>>>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>>> Sent: Friday, 9 January, 2015 12:44:20 PM
>>>>>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>>>> Sent: Friday, January 9, 2015 5:02:16 AM
>>>>>>>> Subject: Re: [keycloak-dev] Device registration and verification
>>>>>>>>
>>>>>>>> Requiring email seems unnecessary and awkward to me. The normal flow
>>>>>>>> I've
>>>>>>>> seen (at least on Android) is that you simply login with your
>>>>>>>> username
>>>>>>>> and
>>>>>>>> password on the device. You can then go into your account later and
>>>>>>>> list
>>>>>>>> devices that are registered.
>>>>>>>
>>>>>>> I was thinking more about browser-based scenarios. Mobile behaves
>>>>>>> differently
>>>>>>> but similary. In any case, the idea is secure user account based on the
>>>>>>> devices he usually use to access something. If that changes, it might
>>>>>>> be
>>>>>>> a
>>>>>>> threat.
>>>>>>
>>>>>> Sure, but what you're actually talking about here is using email as a
>>>>>> 2nd
>>>>>> factor authentication right?
>>>>>
>>>>> No. Email is not a 2nd factor authentication, but the code itself. Email
>>>>> is
>>>>> just how you send the code and also how you alert the user that someone
>>>>> is
>>>>> trying to access his account from a not recognized device. In this case,
>>>>> the
>>>>> code is just an "activation code" (not an authentication code), we can
>>>>> even
>>>>> remove the code and just provide a confirmation link, for instance.
>>>>>
>>>>> This is not about authenticating users, but authorization. Allowing
>>>>> access
>>>>> only from devices previously approved by the user. Let's say you usually
>>>>> access your bank from your home computer. But for some reason, you need
>>>>> temporary access from a LAN house computer. You probably don't want to
>>>>> allow
>>>>> access from LAN house computers later on.
>>>>>
>>>>>>
>>>>>> My plan was that we'd have more ways to do 2nd factor auth (sms, email,
>>>>>> google authenticator, yubikey, custom) and have an option on a realm to
>>>>>> enable "trusted" devices. If the realm has trusted devices enabled then
>>>>>> the
>>>>>> user only has to use the 2nd factor authentication say every 30 days or
>>>>>> so.
>>>>>
>>>>> What I'm proposing is another security layer, which can be used together
>>>>> with
>>>>> 2nd factor authentication.
>>>>
>>>> I see no difference, except for implementation details
>>>
>>> There is a difference. Usually you see this feature in bank sites. Or even
>>> in SalesForce if you try it out. It helps providers to increase security
>>> by allowing access only from devices authorized by the user. You can even
>>> not use 2nd factor authentication at all.
>>>
>>
>> How is this different than a "remember me" button?
>
> "Remember me" will allow you to get authenticated. But if you provided only temporary access from that device, you will not be able to proceed even with "remember me" checked. However, if that device was approved for you and marked as "trusted" you will be fine.
>
> This is not about authentication, but authorization ....
>

Remember me is the same thing as authorizing your browser/machine.



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

From stian at redhat.com  Mon Jan 12 12:54:05 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 12:54:05 -0500 (EST)
Subject: [keycloak-dev] release very soon?
In-Reply-To: <54B3EB02.5@redhat.com>
References: <54B3EB02.5@redhat.com>
Message-ID: <1697028219.8523173.1421085245151.JavaMail.zimbra@redhat.com>

Did you miss my email?

I've done a branch for 1.1.x release so you and Pedro can get on with 1.2 features in master. I hope to release tomorrow or Wednesday, but there's still a couple things to sort out first.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 January, 2015 4:40:50 PM
> Subject: [keycloak-dev] release very soon?
> 
> Are we gonna release very soon?  I'm nervous about conflicting with
> Pedro's work and want 1.1 released so I can start on new stuff.
> --
> 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  Mon Jan 12 13:00:10 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 12 Jan 2015 13:00:10 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54B40541.80507@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<1209268880.6314846.1420810141078.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
Message-ID: <138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, January 12, 2015 3:32:49 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> 
> 
> On 1/12/2015 10:56 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, January 12, 2015 1:39:35 PM
> >> Subject: Re: [keycloak-dev] Device registration and verification
> >>
> >>
> >>
> >> On 1/12/2015 10:06 AM, Pedro Igor Silva wrote:
> >>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Monday, January 12, 2015 5:01:35 AM
> >>>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>> Sent: Friday, 9 January, 2015 4:09:51 PM
> >>>>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>>> Sent: Friday, January 9, 2015 11:29:01 AM
> >>>>>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>>>> Sent: Friday, 9 January, 2015 12:44:20 PM
> >>>>>>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>>>>> Sent: Friday, January 9, 2015 5:02:16 AM
> >>>>>>>> Subject: Re: [keycloak-dev] Device registration and verification
> >>>>>>>>
> >>>>>>>> Requiring email seems unnecessary and awkward to me. The normal flow
> >>>>>>>> I've
> >>>>>>>> seen (at least on Android) is that you simply login with your
> >>>>>>>> username
> >>>>>>>> and
> >>>>>>>> password on the device. You can then go into your account later and
> >>>>>>>> list
> >>>>>>>> devices that are registered.
> >>>>>>>
> >>>>>>> I was thinking more about browser-based scenarios. Mobile behaves
> >>>>>>> differently
> >>>>>>> but similary. In any case, the idea is secure user account based on
> >>>>>>> the
> >>>>>>> devices he usually use to access something. If that changes, it might
> >>>>>>> be
> >>>>>>> a
> >>>>>>> threat.
> >>>>>>
> >>>>>> Sure, but what you're actually talking about here is using email as a
> >>>>>> 2nd
> >>>>>> factor authentication right?
> >>>>>
> >>>>> No. Email is not a 2nd factor authentication, but the code itself.
> >>>>> Email
> >>>>> is
> >>>>> just how you send the code and also how you alert the user that someone
> >>>>> is
> >>>>> trying to access his account from a not recognized device. In this
> >>>>> case,
> >>>>> the
> >>>>> code is just an "activation code" (not an authentication code), we can
> >>>>> even
> >>>>> remove the code and just provide a confirmation link, for instance.
> >>>>>
> >>>>> This is not about authenticating users, but authorization. Allowing
> >>>>> access
> >>>>> only from devices previously approved by the user. Let's say you
> >>>>> usually
> >>>>> access your bank from your home computer. But for some reason, you need
> >>>>> temporary access from a LAN house computer. You probably don't want to
> >>>>> allow
> >>>>> access from LAN house computers later on.
> >>>>>
> >>>>>>
> >>>>>> My plan was that we'd have more ways to do 2nd factor auth (sms,
> >>>>>> email,
> >>>>>> google authenticator, yubikey, custom) and have an option on a realm
> >>>>>> to
> >>>>>> enable "trusted" devices. If the realm has trusted devices enabled
> >>>>>> then
> >>>>>> the
> >>>>>> user only has to use the 2nd factor authentication say every 30 days
> >>>>>> or
> >>>>>> so.
> >>>>>
> >>>>> What I'm proposing is another security layer, which can be used
> >>>>> together
> >>>>> with
> >>>>> 2nd factor authentication.
> >>>>
> >>>> I see no difference, except for implementation details
> >>>
> >>> There is a difference. Usually you see this feature in bank sites. Or
> >>> even
> >>> in SalesForce if you try it out. It helps providers to increase security
> >>> by allowing access only from devices authorized by the user. You can even
> >>> not use 2nd factor authentication at all.
> >>>
> >>
> >> How is this different than a "remember me" button?
> >
> > "Remember me" will allow you to get authenticated. But if you provided only
> > temporary access from that device, you will not be able to proceed even
> > with "remember me" checked. However, if that device was approved for you
> > and marked as "trusted" you will be fine.
> >
> > This is not about authentication, but authorization ....
> >
> 
> Remember me is the same thing as authorizing your browser/machine.

Yes. But you don't track the devices (or pcs), when was your last login from a device, define how long you want to "remember" that device or if you just want a single access from that computer, 
receive notifications from access from unauthorized devices and so forth.

In a sense that is much more than just seamless authenticate (and authorize that computer) the user.

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

From gcardoso at redhat.com  Mon Jan 12 13:01:38 2015
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Mon, 12 Jan 2015 16:01:38 -0200
Subject: [keycloak-dev] Poll - should we replace the Keycloak logo?
In-Reply-To: <312166943.8277876.1421071274320.JavaMail.zimbra@redhat.com>
References: <1421216313.8270401.1421070736979.JavaMail.zimbra@redhat.com>
	<54B3D2A1.3050508@redhat.com>
	<312166943.8277876.1421071274320.JavaMail.zimbra@redhat.com>
Message-ID: <95AF6EE7-2A27-4C4D-80D7-D0B64AF9EEB0@redhat.com>

I think you liked the logo, Bill.

Why do you guys want to change it? Just curious.

Gabriel

> On Jan 12, 2015, at 12:01 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>, mw-security-core at redhat.com
>> Sent: Monday, 12 January, 2015 2:56:49 PM
>> Subject: Re: Poll - should we replace the Keycloak logo?
>> 
>> YOu know my opinion.  I hate logos with a cartoon character.  I was
>> outvoted though when we first did things...
>> 
>> BTW, we have premade alternatives that Gabriel did.  That is an option too.
> 
> Do you have them?
> 
>> 
>> On 1/12/2015 8:52 AM, Stian Thorgersen wrote:
>>> If we want to replace the Keycloak logo we can get the jboss.org design
>>> team to come up with one for us. This doesn't guarantee that we'll get
>>> anything better than we already have, but in that case we'll just stick
>>> with what we got.
>>> 
>>> So! Do we want a new one or not? Please vote
>>> https://doodle.com/vqqtfi3gvrkmsy48
>>> 
>>> 
>> 
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> 
>> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

---
Gabriel Cardoso
User Experience Designer @ Red Hat

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

From stian at redhat.com  Mon Jan 12 13:10:40 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 12 Jan 2015 13:10:40 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
Message-ID: <773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 January, 2015 7:00:10 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Monday, January 12, 2015 3:32:49 PM
> > Subject: Re: [keycloak-dev] Device registration and verification
> > 
> > 
> > 
> > On 1/12/2015 10:56 AM, Pedro Igor Silva wrote:
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Monday, January 12, 2015 1:39:35 PM
> > >> Subject: Re: [keycloak-dev] Device registration and verification
> > >>
> > >>
> > >>
> > >> On 1/12/2015 10:06 AM, Pedro Igor Silva wrote:
> > >>> ----- Original Message -----
> > >>>> From: "Stian Thorgersen" <stian at redhat.com>
> > >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>>> Sent: Monday, January 12, 2015 5:01:35 AM
> > >>>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>>
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>>>> Sent: Friday, 9 January, 2015 4:09:51 PM
> > >>>>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> > >>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>>>>> Sent: Friday, January 9, 2015 11:29:01 AM
> > >>>>>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>>>>>> Sent: Friday, 9 January, 2015 12:44:20 PM
> > >>>>>>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>>>>>
> > >>>>>>> ----- Original Message -----
> > >>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> > >>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>>>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>>>>>>> Sent: Friday, January 9, 2015 5:02:16 AM
> > >>>>>>>> Subject: Re: [keycloak-dev] Device registration and verification
> > >>>>>>>>
> > >>>>>>>> Requiring email seems unnecessary and awkward to me. The normal
> > >>>>>>>> flow
> > >>>>>>>> I've
> > >>>>>>>> seen (at least on Android) is that you simply login with your
> > >>>>>>>> username
> > >>>>>>>> and
> > >>>>>>>> password on the device. You can then go into your account later
> > >>>>>>>> and
> > >>>>>>>> list
> > >>>>>>>> devices that are registered.
> > >>>>>>>
> > >>>>>>> I was thinking more about browser-based scenarios. Mobile behaves
> > >>>>>>> differently
> > >>>>>>> but similary. In any case, the idea is secure user account based on
> > >>>>>>> the
> > >>>>>>> devices he usually use to access something. If that changes, it
> > >>>>>>> might
> > >>>>>>> be
> > >>>>>>> a
> > >>>>>>> threat.
> > >>>>>>
> > >>>>>> Sure, but what you're actually talking about here is using email as
> > >>>>>> a
> > >>>>>> 2nd
> > >>>>>> factor authentication right?
> > >>>>>
> > >>>>> No. Email is not a 2nd factor authentication, but the code itself.
> > >>>>> Email
> > >>>>> is
> > >>>>> just how you send the code and also how you alert the user that
> > >>>>> someone
> > >>>>> is
> > >>>>> trying to access his account from a not recognized device. In this
> > >>>>> case,
> > >>>>> the
> > >>>>> code is just an "activation code" (not an authentication code), we
> > >>>>> can
> > >>>>> even
> > >>>>> remove the code and just provide a confirmation link, for instance.
> > >>>>>
> > >>>>> This is not about authenticating users, but authorization. Allowing
> > >>>>> access
> > >>>>> only from devices previously approved by the user. Let's say you
> > >>>>> usually
> > >>>>> access your bank from your home computer. But for some reason, you
> > >>>>> need
> > >>>>> temporary access from a LAN house computer. You probably don't want
> > >>>>> to
> > >>>>> allow
> > >>>>> access from LAN house computers later on.
> > >>>>>
> > >>>>>>
> > >>>>>> My plan was that we'd have more ways to do 2nd factor auth (sms,
> > >>>>>> email,
> > >>>>>> google authenticator, yubikey, custom) and have an option on a realm
> > >>>>>> to
> > >>>>>> enable "trusted" devices. If the realm has trusted devices enabled
> > >>>>>> then
> > >>>>>> the
> > >>>>>> user only has to use the 2nd factor authentication say every 30 days
> > >>>>>> or
> > >>>>>> so.
> > >>>>>
> > >>>>> What I'm proposing is another security layer, which can be used
> > >>>>> together
> > >>>>> with
> > >>>>> 2nd factor authentication.
> > >>>>
> > >>>> I see no difference, except for implementation details
> > >>>
> > >>> There is a difference. Usually you see this feature in bank sites. Or
> > >>> even
> > >>> in SalesForce if you try it out. It helps providers to increase
> > >>> security
> > >>> by allowing access only from devices authorized by the user. You can
> > >>> even
> > >>> not use 2nd factor authentication at all.
> > >>>
> > >>
> > >> How is this different than a "remember me" button?
> > >
> > > "Remember me" will allow you to get authenticated. But if you provided
> > > only
> > > temporary access from that device, you will not be able to proceed even
> > > with "remember me" checked. However, if that device was approved for you
> > > and marked as "trusted" you will be fine.
> > >
> > > This is not about authentication, but authorization ....
> > >
> > 
> > Remember me is the same thing as authorizing your browser/machine.
> 
> Yes. But you don't track the devices (or pcs), when was your last login from
> a device, define how long you want to "remember" that device or if you just
> want a single access from that computer,
> receive notifications from access from unauthorized devices and so forth.
> 
> In a sense that is much more than just seamless authenticate (and authorize
> that computer) the user.

I'm curious to see what you're proposing in a real system, but to me it sounds like it's similar enough that a remember me and multi factor auth mechanism would have the same level of security without complicating things for the user.

> 
> > 
> > 
> > 
> > --
> > 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 coolmind182006 at gmail.com  Mon Jan 12 13:20:24 2015
From: coolmind182006 at gmail.com (coolmind182006 .)
Date: Mon, 12 Jan 2015 23:50:24 +0530
Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
In-Reply-To: <977292214.7534857.1421048407668.JavaMail.zimbra@redhat.com>
References: <CAM7bvCQBnAabSyOPTB=F3-LhhPe1jpvNgmsezAGv4QaaNfTXQw@mail.gmail.com>
	<977292214.7534857.1421048407668.JavaMail.zimbra@redhat.com>
Message-ID: <CAM7bvCSzTupgYmh3uYxkGKe-KXcLc-v_k4cckuEND0YHPws24Q@mail.gmail.com>

Thanks a bundle, Let me know if I have to do anything..



On Mon, Jan 12, 2015 at 1:10 PM, Stian Thorgersen <stian at redhat.com> wrote:

> Awesome, we'd love to pull this in to our GitHub
>
> ----- Original Message -----
> > From: "coolmind182006 ." <coolmind182006 at gmail.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Sunday, 11 January, 2015 12:22:03 PM
> > Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
> >
> >
> > plugin name : keycloak-oauth
> > github account : mnadeem
> > existing repository : https://github.com/mnadeem/jenkins-keycloak-plugin
> > wiki : https://wiki.jenkins-ci.org/display/JENKINS/keycloak-oauth-plugin
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150112/7792ecc9/attachment.html 

From ssilvert at redhat.com  Mon Jan 12 14:12:35 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 12 Jan 2015 14:12:35 -0500
Subject: [keycloak-dev] keycloak/resteasy problem
Message-ID: <54B41CA3.3030109@redhat.com>

I'm trying to call the keycloak rest API using the keycloak admin 
client.  The call works fine from a web app but when I try to do the 
same thing from the keycloak subsystem I get this:

14:01:51,918 ERROR [org.jboss.msc.service.fail] (MSC service thread 
1-15) MSC000001: Failed to start service 
jboss.deployment.unit."VanillaWAR.war".REGISTER: org.jboss.ms
c.service.StartException in service 
jboss.deployment.unit."VanillaWAR.war".REGISTER: JBAS018733: Failed to 
process phase REGISTER of deployment "VanillaWAR.war"
         at 
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) 
[wildfly-server-8.1.0.Final.jar:8.1.0.Final]
         at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) 
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
         at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) 
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
Source) [rt.jar:1.7.0_51]
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
Source) [rt.jar:1.7.0_51]
         at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_51]
Caused by: javax.ws.rs.ProcessingException: Unable to invoke request
         at 
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
         at 
org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
         at 
org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:102)
         at 
org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:62)
         at com.sun.proxy.$Proxy20.grantToken(Unknown Source)
         at 
org.keycloak.admin.client.token.TokenManager.grantToken(TokenManager.java:56)
         at 
org.keycloak.admin.client.token.TokenManager.getAccessToken(TokenManager.java:33)
         at 
org.keycloak.admin.client.token.TokenManager.getAccessTokenString(TokenManager.java:28)
         at org.keycloak.admin.client.Keycloak.<init>(Keycloak.java:28)
         at org.keycloak.admin.client.Keycloak.getInstance(Keycloak.java:36)
         at 
org.keycloak.subsystem.extension.SeamlessSecurityDeploymentProcessor.addDeploymentToAuthServer(SeamlessSecurityDeploymentProcessor.java:117)
         at 
org.keycloak.subsystem.extension.SeamlessSecurityDeploymentProcessor.deploy(SeamlessSecurityDeploymentProcessor.java:104)
         at 
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) 
[wildfly-server-8.1.0.Final.jar:8.1.0.Final]
         ... 5 more
Caused by: javax.ws.rs.ProcessingException: could not find writer for 
content-type application/x-www-form-urlencoded type: javax.ws.rs.core.Form$1
         at 
org.jboss.resteasy.core.interception.ClientWriterInterceptorContext.throwWriterNotFoundException(ClientWriterInterceptorContext.java:40)
         at 
org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.getWriter(AbstractWriterInterceptorContext.java:138)
         at 
org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:117)
         at 
org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.writeRequestBody(ClientInvocation.java:341)
         at 
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.writeRequestBodyToOutputStream(ApacheHttpClient4Engine.java:558)
         at 
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.buildEntity(ApacheHttpClient4Engine.java:524)
         at 
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.loadHttpMethod(ApacheHttpClient4Engine.java:423)
         at 
org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:281)
         ... 17 more

Any ideas?

From daniel.baxter at cira.ca  Mon Jan 12 15:23:42 2015
From: daniel.baxter at cira.ca (Daniel Baxter)
Date: Mon, 12 Jan 2015 20:23:42 +0000
Subject: [keycloak-dev] Slow Direct Grants API endpoint
Message-ID: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>

Hi,

I am attempting to integrate Keycloak into an existing application to replace the homegrown user management system in place. We have a new project built from the ground up on Keycloak 1.0.4.Final which is exhibiting good performance. However this app that I am porting has a remoting component that connects to the server with bare username/password credentials over the EJB Remoting framework. I was hoping to use 1.1.0 (currently Beta2) which provides a DirectAccessGrantsLoginModule which does exactly what I want (turns username and password into a KeycloakPrincipal). However, the turn around time from Keycloak is on the order of several seconds.

I have used a bare REST client to execute the POSTs to both our 1.0.4 Keycloak and 1.1.0 Keycloak instances and have noted an order of magnitude difference in getting a response. Is this a known issue (I cannot find anything in the public bugs/tasks list)? Or is this due to the Beta status leaving additional performance affecting logging or instrumentation in place?

Thanks,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150112/1669f971/attachment-0001.html 

From mposolda at redhat.com  Mon Jan 12 17:13:51 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 12 Jan 2015 23:13:51 +0100
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
Message-ID: <54B4471F.7000409@redhat.com>

This doesn't seem to be expected. Did you try just direct grant api 
endpoint or also some other endpoints? Do you have any performance test 
to share?

Thanks,
Marek

On 12.1.2015 21:23, Daniel Baxter wrote:
>
> Hi,
>
> I am attempting to integrate Keycloak into an existing application to 
> replace the homegrown user management system in place. We have a new 
> project built from the ground up on Keycloak 1.0.4.Final which is 
> exhibiting good performance. However this app that I am porting has a 
> remoting component that connects to the server with bare 
> username/password credentials over the EJB Remoting framework. I was 
> hoping to use 1.1.0 (currently Beta2) which provides a 
> DirectAccessGrantsLoginModule which does exactly what I want (turns 
> username and password into a KeycloakPrincipal). However, the turn 
> around time from Keycloak is on the order of several seconds.
>
> I have used a bare REST client to execute the POSTs to both our 1.0.4 
> Keycloak and 1.1.0 Keycloak instances and have noted an order of 
> magnitude difference in getting a response. Is this a known issue (I 
> cannot find anything in the public bugs/tasks list)? Or is this due to 
> the Beta status leaving additional performance affecting logging or 
> instrumentation in place?
>
> Thanks,
>
> Daniel
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From psilva at redhat.com  Mon Jan 12 22:10:27 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 12 Jan 2015 22:10:27 -0500 (EST)
Subject: [keycloak-dev] release very soon?
In-Reply-To: <54B3EB02.5@redhat.com>
References: <54B3EB02.5@redhat.com>
Message-ID: <1011231264.7951226.1421118627124.JavaMail.zimbra@redhat.com>

Hey Bill and All,

    I've sent a PR [1] with my initial changes. Please let me know if you need anything.

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

Regards.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Monday, January 12, 2015 1:40:50 PM
Subject: [keycloak-dev] release very soon?

Are we gonna release very soon?  I'm nervous about conflicting with 
Pedro's work and want 1.1 released so I can start on new stuff.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Tue Jan 13 09:35:18 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 13 Jan 2015 09:35:18 -0500
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
	<773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>
Message-ID: <54B52D26.2070802@redhat.com>



On 1/12/2015 1:10 PM, Stian Thorgersen wrote:
>> In a sense that is much more than just seamless authenticate (and authorize
>> that computer) the user.
>
> I'm curious to see what you're proposing in a real system, but to me it sounds like it's similar enough that a remember me and multi factor auth mechanism would have the same level of security without complicating things for the user.
>

I don't think we need any special device registration and verification 
for users.  Any type of client registration should be done by app devs, 
not users.

For browsers, "remember me" and a persistent cookie is good enough.  For 
mobile and native apps, a refresh token can be stored.  We should 
probably have per-client overrides for things like access and refresh 
token timeouts.  We'll eventually add Client IP features so that a user 
doesn't have to use 2-factor auth if they are logging in from the same 
device from the same IP.



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

From stian at redhat.com  Tue Jan 13 09:37:55 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 13 Jan 2015 09:37:55 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54B52D26.2070802@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
	<773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>
	<54B52D26.2070802@redhat.com>
Message-ID: <1536378095.9365266.1421159875983.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 13 January, 2015 3:35:18 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> 
> 
> On 1/12/2015 1:10 PM, Stian Thorgersen wrote:
> >> In a sense that is much more than just seamless authenticate (and
> >> authorize
> >> that computer) the user.
> >
> > I'm curious to see what you're proposing in a real system, but to me it
> > sounds like it's similar enough that a remember me and multi factor auth
> > mechanism would have the same level of security without complicating
> > things for the user.
> >
> 
> I don't think we need any special device registration and verification
> for users.  Any type of client registration should be done by app devs,
> not users.
> 
> For browsers, "remember me" and a persistent cookie is good enough.  For
> mobile and native apps, a refresh token can be stored.  We should
> probably have per-client overrides for things like access and refresh
> token timeouts.  We'll eventually add Client IP features so that a user
> doesn't have to use 2-factor auth if they are logging in from the same
> device from the same IP.

IMO not requiring 2-factor auth from same device should use a cookie not IP

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

From bruno at abstractj.org  Tue Jan 13 09:45:07 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 13 Jan 2015 12:45:07 -0200
Subject: [keycloak-dev] NPE after migrate to 1.1.0.x series
Message-ID: <20150113144507.GB95244@abstractj.org>

Good morning, after banging my head against the wall I decided to ask for help. We started the
tests with Keycloak 1.1.0.Beta1 and Beta2, although after deploying it we get NPE on UPS.

What I identified was that after the commit 94de88ef3b305ad971f81d8610e98a5297f97cd0 the DefaultKeycloakSession
will raise the NPE at:

 public <T extends Provider> T getProvider(Class<T> clazz) {
        Integer hash = clazz.hashCode();
        T provider = (T) providers.get(hash);
        if (provider == null) {
            ProviderFactory<T> providerFactory = factory.getProviderFactory(clazz);
            if (providerFactory != null) {
                provider = providerFactory.create(this);
                providers.put(hash, provider);
            }
        }
        return provider; //Provider will return null here
    }

Maybe is some misconfiguration at https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/resources/META-INF/keycloak-server.json, but after dig into KC sources I couldn't find anything weird.

To reproduce the issues with WildFly 8.2.0.final just go to keycloak/project-integrations and run: mvn -Pwildfly clean install wildfly:deploy.

Thanks in advance.

--

abstractj
PGP: 0x84DC9914

From stian at redhat.com  Tue Jan 13 09:51:46 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 13 Jan 2015 09:51:46 -0500 (EST)
Subject: [keycloak-dev] NPE after migrate to 1.1.0.x series
In-Reply-To: <20150113144507.GB95244@abstractj.org>
References: <20150113144507.GB95244@abstractj.org>
Message-ID: <1599659863.9378951.1421160706414.JavaMail.zimbra@redhat.com>

Can you create a JIRA so we don't miss fixing it for 1.1.0.Final?

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 13 January, 2015 3:45:07 PM
> Subject: [keycloak-dev] NPE after migrate to 1.1.0.x series
> 
> Good morning, after banging my head against the wall I decided to ask for
> help. We started the
> tests with Keycloak 1.1.0.Beta1 and Beta2, although after deploying it we get
> NPE on UPS.
> 
> What I identified was that after the commit
> 94de88ef3b305ad971f81d8610e98a5297f97cd0 the DefaultKeycloakSession
> will raise the NPE at:
> 
>  public <T extends Provider> T getProvider(Class<T> clazz) {
>         Integer hash = clazz.hashCode();
>         T provider = (T) providers.get(hash);
>         if (provider == null) {
>             ProviderFactory<T> providerFactory =
>             factory.getProviderFactory(clazz);
>             if (providerFactory != null) {
>                 provider = providerFactory.create(this);
>                 providers.put(hash, provider);
>             }
>         }
>         return provider; //Provider will return null here
>     }
> 
> Maybe is some misconfiguration at
> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/resources/META-INF/keycloak-server.json,
> but after dig into KC sources I couldn't find anything weird.
> 
> To reproduce the issues with WildFly 8.2.0.final just go to
> keycloak/project-integrations and run: mvn -Pwildfly clean install
> wildfly:deploy.
> 
> Thanks in advance.
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From psilva at redhat.com  Tue Jan 13 10:10:16 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 13 Jan 2015 10:10:16 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54B52D26.2070802@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
	<773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>
	<54B52D26.2070802@redhat.com>
Message-ID: <508939794.8135357.1421161816217.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 13, 2015 12:35:18 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> 
> 
> On 1/12/2015 1:10 PM, Stian Thorgersen wrote:
> >> In a sense that is much more than just seamless authenticate (and
> >> authorize
> >> that computer) the user.
> >
> > I'm curious to see what you're proposing in a real system, but to me it
> > sounds like it's similar enough that a remember me and multi factor auth
> > mechanism would have the same level of security without complicating
> > things for the user.
> >
> 
> I don't think we need any special device registration and verification
> for users.  Any type of client registration should be done by app devs,
> not users.
> 
> For browsers, "remember me" and a persistent cookie is good enough.  For
> mobile and native apps, a refresh token can be stored.  We should
> probably have per-client overrides for things like access and refresh
> token timeouts.  We'll eventually add Client IP features so that a user
> doesn't have to use 2-factor auth if they are logging in from the same
> device from the same IP.

My proposal is all based on browsers, people using their desktops. So you can have an alias for a computer and use a cookie + IP (or even track information from the user-agent) to support the features I suggested before. If IP changed or user is using a unrecognized user-agent you notify the user. Sometimes this sucks, because your IP may change often depending on your network, but I think it is a nice feature to have.

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

From ssilvert at redhat.com  Tue Jan 13 10:22:08 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 13 Jan 2015 10:22:08 -0500
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54B52D26.2070802@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>
	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
	<773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>
	<54B52D26.2070802@redhat.com>
Message-ID: <54B53820.6070204@redhat.com>

On 1/13/2015 9:35 AM, Bill Burke wrote:
>
> On 1/12/2015 1:10 PM, Stian Thorgersen wrote:
>>> In a sense that is much more than just seamless authenticate (and authorize
>>> that computer) the user.
>> I'm curious to see what you're proposing in a real system, but to me it sounds like it's similar enough that a remember me and multi factor auth mechanism would have the same level of security without complicating things for the user.
>>
> I don't think we need any special device registration and verification
> for users.  Any type of client registration should be done by app devs,
> not users.
>
> For browsers, "remember me" and a persistent cookie is good enough.  For
> mobile and native apps, a refresh token can be stored.  We should
> probably have per-client overrides for things like access and refresh
> token timeouts.  We'll eventually add Client IP features so that a user
> doesn't have to use 2-factor auth if they are logging in from the same
> device from the same IP.
I can tell you what my bank does.  I have the usual login/remember me 
function.  But if I want to access something that is more sensitive than 
my basic account balance and such, I need to authorize my device.  This 
is done by getting the bank to send me a code via email or text.  I then 
enter the code in the site and I'm issued a cookie so that the device 
doesn't have to go through this process again.

So this is quite different from "remember me", which only applies to 
authentication.  If someone finds out my credentials they still can't 
get high level authorization to my account without physical access to my 
device.

IMO, it would be a nice feature to implement in keycloak so that app 
devs don't have to.

From bburke at redhat.com  Tue Jan 13 10:26:42 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 13 Jan 2015 10:26:42 -0500
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <508939794.8135357.1421161816217.JavaMail.zimbra@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>
	<54B3EAB7.1020801@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
	<773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>
	<54B52D26.2070802@redhat.com>
	<508939794.8135357.1421161816217.JavaMail.zimbra@redhat.com>
Message-ID: <54B53932.5060302@redhat.com>



On 1/13/2015 10:10 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, January 13, 2015 12:35:18 PM
>> Subject: Re: [keycloak-dev] Device registration and verification
>>
>>
>>
>> On 1/12/2015 1:10 PM, Stian Thorgersen wrote:
>>>> In a sense that is much more than just seamless authenticate (and
>>>> authorize
>>>> that computer) the user.
>>>
>>> I'm curious to see what you're proposing in a real system, but to me it
>>> sounds like it's similar enough that a remember me and multi factor auth
>>> mechanism would have the same level of security without complicating
>>> things for the user.
>>>
>>
>> I don't think we need any special device registration and verification
>> for users.  Any type of client registration should be done by app devs,
>> not users.
>>
>> For browsers, "remember me" and a persistent cookie is good enough.  For
>> mobile and native apps, a refresh token can be stored.  We should
>> probably have per-client overrides for things like access and refresh
>> token timeouts.  We'll eventually add Client IP features so that a user
>> doesn't have to use 2-factor auth if they are logging in from the same
>> device from the same IP.
>
> My proposal is all based on browsers, people using their desktops. So you can have an alias for a computer and use a cookie + IP (or even track information from the user-agent) to support the features I suggested before. If IP changed or user is using a unrecognized user-agent you notify the user. Sometimes this sucks, because your IP may change often depending on your network, but I think it is a nice feature to have.
>

As long as there is no extra steps for the user, it is a fine idea. Same 
goes for any special SPI.  No new special SPIs for this type of thing.

For a long time I've wanted the ability to warn the user if there was a 
login from rogue hacker nation.  Countries and even states, counties and 
cities are assigned specific IP address masks.  I'm pretty sure ISPs are 
assigned specific ones too.  There's a free country IP database you can 
download with the option to pay for more fine-grain information.

BTW, I already had this on my task list for a long time and really 
wanted to do this work.


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

From psilva at redhat.com  Tue Jan 13 10:41:08 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 13 Jan 2015 10:41:08 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54B53932.5060302@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
	<773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>
	<54B52D26.2070802@redhat.com>
	<508939794.8135357.1421161816217.JavaMail.zimbra@redhat.com>
	<54B53932.5060302@redhat.com>
Message-ID: <1370598792.8156287.1421163668536.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 13, 2015 1:26:42 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> 
> 
> On 1/13/2015 10:10 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva"
> >> <psilva at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, January 13, 2015 12:35:18 PM
> >> Subject: Re: [keycloak-dev] Device registration and verification
> >>
> >>
> >>
> >> On 1/12/2015 1:10 PM, Stian Thorgersen wrote:
> >>>> In a sense that is much more than just seamless authenticate (and
> >>>> authorize
> >>>> that computer) the user.
> >>>
> >>> I'm curious to see what you're proposing in a real system, but to me it
> >>> sounds like it's similar enough that a remember me and multi factor auth
> >>> mechanism would have the same level of security without complicating
> >>> things for the user.
> >>>
> >>
> >> I don't think we need any special device registration and verification
> >> for users.  Any type of client registration should be done by app devs,
> >> not users.
> >>
> >> For browsers, "remember me" and a persistent cookie is good enough.  For
> >> mobile and native apps, a refresh token can be stored.  We should
> >> probably have per-client overrides for things like access and refresh
> >> token timeouts.  We'll eventually add Client IP features so that a user
> >> doesn't have to use 2-factor auth if they are logging in from the same
> >> device from the same IP.
> >
> > My proposal is all based on browsers, people using their desktops. So you
> > can have an alias for a computer and use a cookie + IP (or even track
> > information from the user-agent) to support the features I suggested
> > before. If IP changed or user is using a unrecognized user-agent you
> > notify the user. Sometimes this sucks, because your IP may change often
> > depending on your network, but I think it is a nice feature to have.
> >
> 
> As long as there is no extra steps for the user, it is a fine idea. Same
> goes for any special SPI.  No new special SPIs for this type of thing.
> 
> For a long time I've wanted the ability to warn the user if there was a
> login from rogue hacker nation.  Countries and even states, counties and
> cities are assigned specific IP address masks.  I'm pretty sure ISPs are
> assigned specific ones too.  There's a free country IP database you can
> download with the option to pay for more fine-grain information.
> 
> BTW, I already had this on my task list for a long time and really
> wanted to do this work.

Sure :)

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

From bburke at redhat.com  Tue Jan 13 10:42:07 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 13 Jan 2015 10:42:07 -0500
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54B53820.6070204@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>	<482904776.6612656.1420816191984.JavaMail.zimbra@redhat.com>	<1554725189.7529555.1421046095622.JavaMail.zimbra@redhat.com>	<1934885414.7407563.1421075183520.JavaMail.zimbra@redhat.com>	<54B3EAB7.1020801@redhat.com>	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>	<54B40541.80507@redhat.com>	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>	<773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>	<54B52D26.2070802@redhat.com>
	<54B53820.6070204@redhat.com>
Message-ID: <54B53CCF.70803@redhat.com>



On 1/13/2015 10:22 AM, Stan Silvert wrote:
> On 1/13/2015 9:35 AM, Bill Burke wrote:
>>
>> On 1/12/2015 1:10 PM, Stian Thorgersen wrote:
>>>> In a sense that is much more than just seamless authenticate (and authorize
>>>> that computer) the user.
>>> I'm curious to see what you're proposing in a real system, but to me it sounds like it's similar enough that a remember me and multi factor auth mechanism would have the same level of security without complicating things for the user.
>>>
>> I don't think we need any special device registration and verification
>> for users.  Any type of client registration should be done by app devs,
>> not users.
>>
>> For browsers, "remember me" and a persistent cookie is good enough.  For
>> mobile and native apps, a refresh token can be stored.  We should
>> probably have per-client overrides for things like access and refresh
>> token timeouts.  We'll eventually add Client IP features so that a user
>> doesn't have to use 2-factor auth if they are logging in from the same
>> device from the same IP.
> I can tell you what my bank does.  I have the usual login/remember me
> function.  But if I want to access something that is more sensitive than
> my basic account balance and such, I need to authorize my device.  This
> is done by getting the bank to send me a code via email or text.  I then
> enter the code in the site and I'm issued a cookie so that the device
> doesn't have to go through this process again.
>

I would suggest the bank use OTP rather than this device registration 
you talk of.

> So this is quite different from "remember me", which only applies to
> authentication.  If someone finds out my credentials they still can't
> get high level authorization to my account without physical access to my
> device.
>

This is no different than OTP.  Hacker could find a user's password, but 
they still need the OTP device to log in.

> IMO, it would be a nice feature to implement in keycloak so that app
> devs don't have to.

IMO, too many ways to do the same thing is not a good idea.  App devs 
should use OTP.

How you set up OTP is another separate matter.  For example, World of 
Warcraft has OTP.  The OTP generator is set up *PER DEVICE*.  So if you 
lose your iphone, you have to call up Blizzard support and answer a 
bunch of personal questions before they disable OTP.  The other option 
they have is for you to register your mobile number.  So, if you lose 
you iphone and get another, you can disable OTP through an SMS exchange 
with your new iphone.


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

From bburke at redhat.com  Tue Jan 13 11:01:42 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 13 Jan 2015 11:01:42 -0500
Subject: [keycloak-dev] logout by redirect
Message-ID: <54B54166.5030600@redhat.com>

* Adding a flag to ClientModel "backchannelLogout"
* Adding a method to LoginProtocol "Response 
redirectLogout(UserSessionModel, ClientSessionModel)"
* Adding a flag to ClientSessionModel "loggedOut" ... or ... rename the 
Action attribute to State and add a "LOGGED_OUT" state.
* Adding a redirectLogout REST endpoint for OIDC.
* Adding a redirectLogout REST endpoint for adapters.

Algorithm will be:
1. do all backchannel logouts
2. Find a logged in client
3. Redirect based on protocol
4. Receive logout success from a redirection, goto 2

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

From bburke at redhat.com  Tue Jan 13 11:11:09 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 13 Jan 2015 11:11:09 -0500
Subject: [keycloak-dev] Why do I have to enter the OTP?
Message-ID: <54B5439D.2040909@redhat.com>

Why does a user have to enter in the OTP generated by their mobile 
device?  Wouldn't it be cooler if the steps were:

1. Enter in username password in the browser
2. Browser blocks and wait for...
3. Press a button on your OTP iphone app
4. iphone app sends an HTTP message to Keycloak with username and 
generated OTP (in background)
5. Keycloak sees if a browser app is waiting for OTP verification, then 
verifies OTP if so.
6. Browser unblocks and lets user in.

Now, the user doesn't ever have to enter the OTP (and mess it up like I 
do all the time).  They just need their mobile device.



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

From supittma at redhat.com  Tue Jan 13 11:19:38 2015
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 13 Jan 2015 11:19:38 -0500
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B5439D.2040909@redhat.com>
References: <54B5439D.2040909@redhat.com>
Message-ID: <54B5459A.5000701@redhat.com>

On 01/13/2015 11:11 AM, Bill Burke wrote:
> Why does a user have to enter in the OTP generated by their mobile
> device?  Wouldn't it be cooler if the steps were:
>
> 1. Enter in username password in the browser
> 2. Browser blocks and wait for...
> 3. Press a button on your OTP iphone app
> 4. iphone app sends an HTTP message to Keycloak with username and
> generated OTP (in background)
> 5. Keycloak sees if a browser app is waiting for OTP verification, then
> verifies OTP if so.
> 6. Browser unblocks and lets user in.
>
> Now, the user doesn't ever have to enter the OTP (and mess it up like I
> do all the time).  They just need their mobile device.
>
>
>
Even better, in Android this can be done from an interactive 
notification.  You won't even need to open the app.

-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.


From bburke at redhat.com  Tue Jan 13 11:20:32 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 13 Jan 2015 11:20:32 -0500
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B5459A.5000701@redhat.com>
References: <54B5439D.2040909@redhat.com> <54B5459A.5000701@redhat.com>
Message-ID: <54B545D0.9020309@redhat.com>



On 1/13/2015 11:19 AM, Summers Pittman wrote:
> On 01/13/2015 11:11 AM, Bill Burke wrote:
>> Why does a user have to enter in the OTP generated by their mobile
>> device?  Wouldn't it be cooler if the steps were:
>>
>> 1. Enter in username password in the browser
>> 2. Browser blocks and wait for...
>> 3. Press a button on your OTP iphone app
>> 4. iphone app sends an HTTP message to Keycloak with username and
>> generated OTP (in background)
>> 5. Keycloak sees if a browser app is waiting for OTP verification, then
>> verifies OTP if so.
>> 6. Browser unblocks and lets user in.
>>
>> Now, the user doesn't ever have to enter the OTP (and mess it up like I
>> do all the time).  They just need their mobile device.
>>
>>
>>
> Even better, in Android this can be done from an interactive
> notification.  You won't even need to open the app.
>

Probably the same in iOS, no?

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

From bruno at abstractj.org  Tue Jan 13 11:34:23 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 13 Jan 2015 14:34:23 -0200
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B545D0.9020309@redhat.com>
References: <54B5439D.2040909@redhat.com> <54B5459A.5000701@redhat.com>
	<54B545D0.9020309@redhat.com>
Message-ID: <20150113163423.GA97100@abstractj.org>

I think what you meant was something like this
https://www.duosecurity.com/product/user-experience/authentication,
right?

On 2015-01-13, Bill Burke wrote:
>
>
> On 1/13/2015 11:19 AM, Summers Pittman wrote:
> > On 01/13/2015 11:11 AM, Bill Burke wrote:
> >> Why does a user have to enter in the OTP generated by their mobile
> >> device?  Wouldn't it be cooler if the steps were:
> >>
> >> 1. Enter in username password in the browser
> >> 2. Browser blocks and wait for...
> >> 3. Press a button on your OTP iphone app
> >> 4. iphone app sends an HTTP message to Keycloak with username and
> >> generated OTP (in background)
> >> 5. Keycloak sees if a browser app is waiting for OTP verification, then
> >> verifies OTP if so.
> >> 6. Browser unblocks and lets user in.
> >>
> >> Now, the user doesn't ever have to enter the OTP (and mess it up like I
> >> do all the time).  They just need their mobile device.
> >>
> >>
> >>
> > Even better, in Android this can be done from an interactive
> > notification.  You won't even need to open the app.
> >
>
> Probably the same in iOS, no?
>
> --
> 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

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Tue Jan 13 11:41:33 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 13 Jan 2015 11:41:33 -0500
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <20150113163423.GA97100@abstractj.org>
References: <54B5439D.2040909@redhat.com> <54B5459A.5000701@redhat.com>
	<54B545D0.9020309@redhat.com>
	<20150113163423.GA97100@abstractj.org>
Message-ID: <54B54ABD.7060101@redhat.com>

Cool.  I knew it couldn't be a unique idea.

On 1/13/2015 11:34 AM, Bruno Oliveira wrote:
> I think what you meant was something like this
> https://www.duosecurity.com/product/user-experience/authentication,
> right?
>
> On 2015-01-13, Bill Burke wrote:
>>
>>
>> On 1/13/2015 11:19 AM, Summers Pittman wrote:
>>> On 01/13/2015 11:11 AM, Bill Burke wrote:
>>>> Why does a user have to enter in the OTP generated by their mobile
>>>> device?  Wouldn't it be cooler if the steps were:
>>>>
>>>> 1. Enter in username password in the browser
>>>> 2. Browser blocks and wait for...
>>>> 3. Press a button on your OTP iphone app
>>>> 4. iphone app sends an HTTP message to Keycloak with username and
>>>> generated OTP (in background)
>>>> 5. Keycloak sees if a browser app is waiting for OTP verification, then
>>>> verifies OTP if so.
>>>> 6. Browser unblocks and lets user in.
>>>>
>>>> Now, the user doesn't ever have to enter the OTP (and mess it up like I
>>>> do all the time).  They just need their mobile device.
>>>>
>>>>
>>>>
>>> Even better, in Android this can be done from an interactive
>>> notification.  You won't even need to open the app.
>>>
>>
>> Probably the same in iOS, no?
>>
>> --
>> 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
>
> --
>
> abstractj
> PGP: 0x84DC9914
>

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

From bruno at abstractj.org  Tue Jan 13 12:01:03 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 13 Jan 2015 09:01:03 -0800 (PST)
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B54ABD.7060101@redhat.com>
References: <54B54ABD.7060101@redhat.com>
Message-ID: <1421168463254.66d2ac36@Nodemailer>

That's for sure a great feature for Keycloak +10000. We planned something last year (http://staging.aerogear.org/docs/planning/roadmaps/AeroGearSecurity/), but due to other priorities we didn't even started.



?

abstractj
PGP: 0x84DC9914

On Tue, Jan 13, 2015 at 2:41 PM, Bill Burke <bburke at redhat.com> wrote:

> Cool.  I knew it couldn't be a unique idea.
> On 1/13/2015 11:34 AM, Bruno Oliveira wrote:
>> I think what you meant was something like this
>> https://www.duosecurity.com/product/user-experience/authentication,
>> right?
>>
>> On 2015-01-13, Bill Burke wrote:
>>>
>>>
>>> On 1/13/2015 11:19 AM, Summers Pittman wrote:
>>>> On 01/13/2015 11:11 AM, Bill Burke wrote:
>>>>> Why does a user have to enter in the OTP generated by their mobile
>>>>> device?  Wouldn't it be cooler if the steps were:
>>>>>
>>>>> 1. Enter in username password in the browser
>>>>> 2. Browser blocks and wait for...
>>>>> 3. Press a button on your OTP iphone app
>>>>> 4. iphone app sends an HTTP message to Keycloak with username and
>>>>> generated OTP (in background)
>>>>> 5. Keycloak sees if a browser app is waiting for OTP verification, then
>>>>> verifies OTP if so.
>>>>> 6. Browser unblocks and lets user in.
>>>>>
>>>>> Now, the user doesn't ever have to enter the OTP (and mess it up like I
>>>>> do all the time).  They just need their mobile device.
>>>>>
>>>>>
>>>>>
>>>> Even better, in Android this can be done from an interactive
>>>> notification.  You won't even need to open the app.
>>>>
>>>
>>> Probably the same in iOS, no?
>>>
>>> --
>>> 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
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>>
> -- 
> 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/20150113/6cb18b45/attachment.html 

From dnguyen at ciena.com  Tue Jan 13 12:43:53 2015
From: dnguyen at ciena.com (Nguyen, Dinh)
Date: Tue, 13 Jan 2015 12:43:53 -0500
Subject: [keycloak-dev] Keycloak Wildfly adapter question
Message-ID: <CBB9EF2338BC8042BB19FEA6322FB441A73E63EAEE@ONWVEXCHMB02.ciena.com>

Hi all,
I already have Wildfly 8.1.0.Final installed, and try to install Keycloak war distribtion 1.1.0.Beta2. When deploying the client  Keycload Wildfly adapter dist 1.1.0.Beta2 to Wildfly, I notice that the adapter overrides the some Wildfly module file to use different jar file than the one provided by Wildfly. In particular,
1.            the file ../modules/system/layers/base/org/jboss/as/cli/main/module.xml is replaced to use wildfly-cli-1.0.0.Alpha12.jar instead of the provided file  wildfly-cli-8.1.0.Final.jar.
2.            The file ../modules/system/layers/base/org/jboss/aesh/main/module.xml is replaced to use aesh-0.33.12.jar instead of the Wildfly provided file ash-0.33.11.jar
My question are:
1.            What is the difference of the Wildfly provided jar files and the Keycloak ones?
2.            Why Keycloak uses a different files than the one provided by the Wildfly distribution?
3.            Is there any impact if I uses the Wildfly provided jar files instead of the Keycloak one?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150113/eb74aec5/attachment.html 

From cvasilak at gmail.com  Tue Jan 13 14:21:52 2015
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Tue, 13 Jan 2015 21:21:52 +0200
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B545D0.9020309@redhat.com>
References: <54B5439D.2040909@redhat.com> <54B5459A.5000701@redhat.com>
	<54B545D0.9020309@redhat.com>
Message-ID: <CAKVvow-yv+DnxsEKTM0h7AuBvYCOZJ7UAWhZdEohuo9Y+0-exg@mail.gmail.com>

On Tue, Jan 13, 2015 at 6:20 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 1/13/2015 11:19 AM, Summers Pittman wrote:
> > On 01/13/2015 11:11 AM, Bill Burke wrote:
> >> Why does a user have to enter in the OTP generated by their mobile
> >> device?  Wouldn't it be cooler if the steps were:
> >>
> >> 1. Enter in username password in the browser
> >> 2. Browser blocks and wait for...
> >> 3. Press a button on your OTP iphone app
> >> 4. iphone app sends an HTTP message to Keycloak with username and
> >> generated OTP (in background)
> >> 5. Keycloak sees if a browser app is waiting for OTP verification, then
> >> verifies OTP if so.
> >> 6. Browser unblocks and lets user in.
> >>
> >> Now, the user doesn't ever have to enter the OTP (and mess it up like I
> >> do all the time).  They just need their mobile device.
> >>
> >>
> >>
> > Even better, in Android this can be done from an interactive
> > notification.  You won't even need to open the app.
> >
>
> Probably the same in iOS, no?
>

the same 'interactive notification' concept exist in iOS too, that is
without launching the app in the foreground, instead allowing the user to
click 'Accept/Send OTP" in the notification directly and let the system
call your app in the 'background' to process the request.

-
Christos




>
> --
> 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/20150113/0af921ef/attachment.html 

From coolmind182006 at gmail.com  Wed Jan 14 00:36:50 2015
From: coolmind182006 at gmail.com (coolmind182006 .)
Date: Wed, 14 Jan 2015 11:06:50 +0530
Subject: [keycloak-dev] Deploying keycloak in non jboss containers
Message-ID: <CAM7bvCRVDDE=Qd=MPb7NHg3Piw3csH964Pt-aF9=A+E-dCvdEg@mail.gmail.com>

I have documented my findings here
<https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomcat/>

https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomcat/

Not sure if it can help the community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150114/cef80c4b/attachment.html 

From juraci at kroehling.de  Wed Jan 14 02:36:54 2015
From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 14 Jan 2015 08:36:54 +0100
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B5439D.2040909@redhat.com>
References: <54B5439D.2040909@redhat.com>
Message-ID: <54B61C96.3090707@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2015 05:11 PM, Bill Burke wrote:
> Why does a user have to enter in the OTP generated by their mobile
>  device?  Wouldn't it be cooler if the steps were:
> 
> 1. Enter in username password in the browser 2. Browser blocks and
> wait for... 3. Press a button on your OTP iphone app 4. iphone app
> sends an HTTP message to Keycloak with username and generated OTP
> (in background) 5. Keycloak sees if a browser app is waiting for
> OTP verification, then verifies OTP if so.

How do you ensure that this browser is the same as the real user, and
not from an attacker?

> 6. Browser unblocks and lets user in.
> 
> Now, the user doesn't ever have to enter the OTP (and mess it up
> like I do all the time).  They just need their mobile device.

I haven't seen any mention of SQRL on this list yet, so, if you are
looking for a way to make the login process "easier" to the final user
(easier being veeery subjective here), then this might be of interest:
https://www.grc.com/sqrl/sqrl.htm

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUthyWAAoJEDnJtskdmzLMU7cIAIQjTD3mMP2FqIpy/0tc82rs
jgjNqZbtKDIMbBPPhSs0jMIoVfqSY/2ybIxMLpXBW2kNLKxVKrz6mY7bbifRlXbK
uvDh8t6LXM45Q6sEetmnTCgxnD1AtbkypJh0RZH6KXUzshQVPqfPaPqCz79p5V32
87XnAUU9hFXL4ECOFSKHOg8KZIkXYwFZb72MmjPWkh6/m85VkDeLvSRtFYczobJZ
Joe71n/rhm+G+pM2uq8jONslKQeqvIluzp6tw3l0CVpez8R/KI/yA/4rnhd4Lj5m
Dkl/0Gha/Q50nyswTAM22jrN8StXvjARCCH8RmqX6DdB6fADCFTVtzloa44WcNM=
=OFPT
-----END PGP SIGNATURE-----

From juraci at kroehling.de  Wed Jan 14 02:52:44 2015
From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 14 Jan 2015 08:52:44 +0100
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B61C96.3090707@kroehling.de>
References: <54B5439D.2040909@redhat.com> <54B61C96.3090707@kroehling.de>
Message-ID: <54B6204C.3000806@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/14/2015 08:36 AM, Juraci Paix?o Kr?hling wrote:
> I haven't seen any mention of SQRL on this list yet, so, if you
> are looking for a way to make the login process "easier" to the
> final user (easier being veeery subjective here), then this might
> be of interest: https://www.grc.com/sqrl/sqrl.htm

By the way: I'm not suggesting SQRL to be implemented in Keycloak, but
to take a look at how it is implemented and use a thing or two from it
when considering the "tap button to login" feature :-)

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUtiBMAAoJEDnJtskdmzLMfekH/AyMm6SXONW/GdhO9koT6Mje
ZCKYPoEJ56l/pDxZvIrUv40og9aThBNdHbTOUCm3jYzGr02ySEd8n8J2JEu3iRvw
VKThGuuwC/QGGUrhq1nsh4oqV/EuHnbvt3S9wnap4TToZD25H6TMUWByzRAiqGU6
KZfK3UnJtryVU0SzvX23S0sppZJGBvKKK5yWPlzh/YTwNpMehsUDY7IIQqW3vUbv
YjufwXT5rR8zIUnZJ/zgPbcASegtlcky6iexSRK2QuQliUD62xRp/4aerENZbQrf
ZXbAd352onhyQk+hPOUPckDmIPAL418jGaxhFqjUSoupht4jWYvKz5H+JGIyeaw=
=y0Ag
-----END PGP SIGNATURE-----

From stian at redhat.com  Wed Jan 14 02:53:33 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 Jan 2015 02:53:33 -0500 (EST)
Subject: [keycloak-dev] Device registration and verification
In-Reply-To: <54B53CCF.70803@redhat.com>
References: <1857149028.6382494.1420758587561.JavaMail.zimbra@redhat.com>
	<1621167644.7494842.1421078209558.JavaMail.zimbra@redhat.com>
	<54B40541.80507@redhat.com>
	<138488470.7593474.1421085610077.JavaMail.zimbra@redhat.com>
	<773141021.8529906.1421086239991.JavaMail.zimbra@redhat.com>
	<54B52D26.2070802@redhat.com> <54B53820.6070204@redhat.com>
	<54B53CCF.70803@redhat.com>
Message-ID: <1947765348.9876910.1421222013961.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 13 January, 2015 4:42:07 PM
> Subject: Re: [keycloak-dev] Device registration and verification
> 
> 
> 
> On 1/13/2015 10:22 AM, Stan Silvert wrote:
> > On 1/13/2015 9:35 AM, Bill Burke wrote:
> >>
> >> On 1/12/2015 1:10 PM, Stian Thorgersen wrote:
> >>>> In a sense that is much more than just seamless authenticate (and
> >>>> authorize
> >>>> that computer) the user.
> >>> I'm curious to see what you're proposing in a real system, but to me it
> >>> sounds like it's similar enough that a remember me and multi factor auth
> >>> mechanism would have the same level of security without complicating
> >>> things for the user.
> >>>
> >> I don't think we need any special device registration and verification
> >> for users.  Any type of client registration should be done by app devs,
> >> not users.
> >>
> >> For browsers, "remember me" and a persistent cookie is good enough.  For
> >> mobile and native apps, a refresh token can be stored.  We should
> >> probably have per-client overrides for things like access and refresh
> >> token timeouts.  We'll eventually add Client IP features so that a user
> >> doesn't have to use 2-factor auth if they are logging in from the same
> >> device from the same IP.
> > I can tell you what my bank does.  I have the usual login/remember me
> > function.  But if I want to access something that is more sensitive than
> > my basic account balance and such, I need to authorize my device.  This
> > is done by getting the bank to send me a code via email or text.  I then
> > enter the code in the site and I'm issued a cookie so that the device
> > doesn't have to go through this process again.
> >
> 
> I would suggest the bank use OTP rather than this device registration
> you talk of.
> 
> > So this is quite different from "remember me", which only applies to
> > authentication.  If someone finds out my credentials they still can't
> > get high level authorization to my account without physical access to my
> > device.
> >
> 
> This is no different than OTP.  Hacker could find a user's password, but
> they still need the OTP device to log in.
> 
> > IMO, it would be a nice feature to implement in keycloak so that app
> > devs don't have to.
> 
> IMO, too many ways to do the same thing is not a good idea.  App devs
> should use OTP.
> 
> How you set up OTP is another separate matter.  For example, World of
> Warcraft has OTP.  The OTP generator is set up *PER DEVICE*.  So if you
> lose your iphone, you have to call up Blizzard support and answer a
> bunch of personal questions before they disable OTP.  The other option
> they have is for you to register your mobile number.  So, if you lose
> you iphone and get another, you can disable OTP through an SMS exchange
> with your new iphone.

There's also multi-level authentication. TOTP can be optional on a new device until you're trying to do something sensitive. The app can then check the authentication level provided for the specific token, if it's not high enough, redirect back to login pages on Keycloak to bump the authentication level (totp, email or whatever).

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

From mposolda at redhat.com  Wed Jan 14 02:57:20 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 14 Jan 2015 08:57:20 +0100
Subject: [keycloak-dev] logout by redirect
In-Reply-To: <54B54166.5030600@redhat.com>
References: <54B54166.5030600@redhat.com>
Message-ID: <54B62160.8010104@redhat.com>

Sounds good to me. +1 for renaming "Action" to "State" on 
ClientSessionModel.

Marek

On 13.1.2015 17:01, Bill Burke wrote:
> * Adding a flag to ClientModel "backchannelLogout"
> * Adding a method to LoginProtocol "Response
> redirectLogout(UserSessionModel, ClientSessionModel)"
> * Adding a flag to ClientSessionModel "loggedOut" ... or ... rename the
> Action attribute to State and add a "LOGGED_OUT" state.
> * Adding a redirectLogout REST endpoint for OIDC.
> * Adding a redirectLogout REST endpoint for adapters.
>
> Algorithm will be:
> 1. do all backchannel logouts
> 2. Find a logged in client
> 3. Redirect based on protocol
> 4. Receive logout success from a redirection, goto 2
>


From stian at redhat.com  Wed Jan 14 03:03:05 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 Jan 2015 03:03:05 -0500 (EST)
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B5439D.2040909@redhat.com>
References: <54B5439D.2040909@redhat.com>
Message-ID: <659701591.9880791.1421222585163.JavaMail.zimbra@redhat.com>

Look at YubiKey and FIDO U2F

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 13 January, 2015 5:11:09 PM
> Subject: [keycloak-dev] Why do I have to enter the OTP?
> 
> Why does a user have to enter in the OTP generated by their mobile
> device?  Wouldn't it be cooler if the steps were:
> 
> 1. Enter in username password in the browser
> 2. Browser blocks and wait for...
> 3. Press a button on your OTP iphone app
> 4. iphone app sends an HTTP message to Keycloak with username and
> generated OTP (in background)
> 5. Keycloak sees if a browser app is waiting for OTP verification, then
> verifies OTP if so.
> 6. Browser unblocks and lets user in.
> 
> Now, the user doesn't ever have to enter the OTP (and mess it up like I
> do all the time).  They just need their mobile device.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jan 14 03:21:47 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 Jan 2015 03:21:47 -0500 (EST)
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <659701591.9880791.1421222585163.JavaMail.zimbra@redhat.com>
References: <54B5439D.2040909@redhat.com>
	<659701591.9880791.1421222585163.JavaMail.zimbra@redhat.com>
Message-ID: <552925103.9889778.1421223707494.JavaMail.zimbra@redhat.com>

Maybe this is something that could be added to FreeOTP? That would be a good reason for folks to switch to Red Hat's over Google's ;)

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 14 January, 2015 9:03:05 AM
> Subject: Re: [keycloak-dev] Why do I have to enter the OTP?
> 
> Look at YubiKey and FIDO U2F
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 13 January, 2015 5:11:09 PM
> > Subject: [keycloak-dev] Why do I have to enter the OTP?
> > 
> > Why does a user have to enter in the OTP generated by their mobile
> > device?  Wouldn't it be cooler if the steps were:
> > 
> > 1. Enter in username password in the browser
> > 2. Browser blocks and wait for...
> > 3. Press a button on your OTP iphone app
> > 4. iphone app sends an HTTP message to Keycloak with username and
> > generated OTP (in background)
> > 5. Keycloak sees if a browser app is waiting for OTP verification, then
> > verifies OTP if so.
> > 6. Browser unblocks and lets user in.
> > 
> > Now, the user doesn't ever have to enter the OTP (and mess it up like I
> > do all the time).  They just need their mobile device.
> > 
> > 
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jan 14 03:41:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 Jan 2015 03:41:54 -0500 (EST)
Subject: [keycloak-dev] oauth vulnerabilities
In-Reply-To: <54ADDE0F.4000700@redhat.com>
References: <54ADDA0B.2060906@redhat.com> <54ADDE0F.4000700@redhat.com>
Message-ID: <1027546757.9896136.1421224914461.JavaMail.zimbra@redhat.com>

I agree we shouldn't allow relative redirect URLs.

We should also improve our wildcard matching to only allow one level, for example:

  http://www.site.com/a/*

Should match:

  http://www.site.com/a/page.html

But not:

  http://www.site.com/a/b/page.html

We don't check the redirect_uri in the access token request either. I've created https://issues.jboss.org/browse/KEYCLOAK-957 for that.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 8 January, 2015 2:31:59 AM
> Subject: Re: [keycloak-dev] oauth vulnerabilities
> 
> Read this one, specifically that attack on github (you have to scroll
> down a bit):
> 
> http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html
> 
> wildcard redirect uri patterns are pretty scary!
> 
> On 1/7/2015 8:14 PM, Bill Burke wrote:
> > http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html
> >
> > I think we're pretty good, the ones I worry about is relative urls in
> > redirect URI checks i.e.
> >
> > "http://cloud.com/provisioned/good-site/../hacker-site"
> >
> > I'll log a bug for this if you agree that relative redirect URLs
> > shouldn't be allowed. (Those containing "." and "..")
> >
> > Another really dangerous thing that we do is have full-scope-allowed set
> > to true by default.  If a rogue client gets registered, they pretty much
> > have access to every single application the user can access with all of
> > their privileges.
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Wed Jan 14 05:33:08 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 14 Jan 2015 11:33:08 +0100
Subject: [keycloak-dev] oauth vulnerabilities
In-Reply-To: <1027546757.9896136.1421224914461.JavaMail.zimbra@redhat.com>
References: <54ADDA0B.2060906@redhat.com> <54ADDE0F.4000700@redhat.com>
	<1027546757.9896136.1421224914461.JavaMail.zimbra@redhat.com>
Message-ID: <54B645E4.7020809@redhat.com>

On 14.1.2015 09:41, Stian Thorgersen wrote:
> I agree we shouldn't allow relative redirect URLs.
>
> We should also improve our wildcard matching to only allow one level, for example:
>
>    http://www.site.com/a/*
>
> Should match:
>
>    http://www.site.com/a/page.html
>
> But not:
>
>    http://www.site.com/a/b/page.html
I wonder that it's quite restrictive and not compatible with other stuff 
using url mappings? For example in servlet specification if you map 
servlet under "/a/*", it would map to everything including 
"/a/b/page.html" .

Isn't it sufficient to just refuse url if it contains dangerous 
characters like dots in the path?

Marek
>
> We don't check the redirect_uri in the access token request either. I've created https://issues.jboss.org/browse/KEYCLOAK-957 for that.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 8 January, 2015 2:31:59 AM
>> Subject: Re: [keycloak-dev] oauth vulnerabilities
>>
>> Read this one, specifically that attack on github (you have to scroll
>> down a bit):
>>
>> http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html
>>
>> wildcard redirect uri patterns are pretty scary!
>>
>> On 1/7/2015 8:14 PM, Bill Burke wrote:
>>> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html
>>>
>>> I think we're pretty good, the ones I worry about is relative urls in
>>> redirect URI checks i.e.
>>>
>>> "http://cloud.com/provisioned/good-site/../hacker-site"
>>>
>>> I'll log a bug for this if you agree that relative redirect URLs
>>> shouldn't be allowed. (Those containing "." and "..")
>>>
>>> Another really dangerous thing that we do is have full-scope-allowed set
>>> to true by default.  If a rogue client gets registered, they pretty much
>>> have access to every single application the user can access with all of
>>> their privileges.
>>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Jan 14 06:32:05 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 Jan 2015 06:32:05 -0500 (EST)
Subject: [keycloak-dev] oauth vulnerabilities
In-Reply-To: <54B645E4.7020809@redhat.com>
References: <54ADDA0B.2060906@redhat.com> <54ADDE0F.4000700@redhat.com>
	<1027546757.9896136.1421224914461.JavaMail.zimbra@redhat.com>
	<54B645E4.7020809@redhat.com>
Message-ID: <659110092.9973630.1421235125108.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 14 January, 2015 11:33:08 AM
> Subject: Re: [keycloak-dev] oauth vulnerabilities
> 
> On 14.1.2015 09:41, Stian Thorgersen wrote:
> > I agree we shouldn't allow relative redirect URLs.
> >
> > We should also improve our wildcard matching to only allow one level, for
> > example:
> >
> >    http://www.site.com/a/*
> >
> > Should match:
> >
> >    http://www.site.com/a/page.html
> >
> > But not:
> >
> >    http://www.site.com/a/b/page.html
> I wonder that it's quite restrictive and not compatible with other stuff
> using url mappings? For example in servlet specification if you map
> servlet under "/a/*", it would map to everything including
> "/a/b/page.html" .
> 
> Isn't it sufficient to just refuse url if it contains dangerous
> characters like dots in the path?

In a servlet environment it's fine, because the url-pattern is relative to the application. So you know all child resources belong to the application.

The problem is that by allowing a recursive wildcard is that it allows a very bad practice which is to share the same client_id and secret for multiple applications. For example an app with redirect 'http://acme.org/*' could be used by all apps under the same domain.

> 
> Marek
> >
> > We don't check the redirect_uri in the access token request either. I've
> > created https://issues.jboss.org/browse/KEYCLOAK-957 for that.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 8 January, 2015 2:31:59 AM
> >> Subject: Re: [keycloak-dev] oauth vulnerabilities
> >>
> >> Read this one, specifically that attack on github (you have to scroll
> >> down a bit):
> >>
> >> http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html
> >>
> >> wildcard redirect uri patterns are pretty scary!
> >>
> >> On 1/7/2015 8:14 PM, Bill Burke wrote:
> >>> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html
> >>>
> >>> I think we're pretty good, the ones I worry about is relative urls in
> >>> redirect URI checks i.e.
> >>>
> >>> "http://cloud.com/provisioned/good-site/../hacker-site"
> >>>
> >>> I'll log a bug for this if you agree that relative redirect URLs
> >>> shouldn't be allowed. (Those containing "." and "..")
> >>>
> >>> Another really dangerous thing that we do is have full-scope-allowed set
> >>> to true by default.  If a rogue client gets registered, they pretty much
> >>> have access to every single application the user can access with all of
> >>> their privileges.
> >>>
> >> --
> >> 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 supittma at redhat.com  Wed Jan 14 08:35:55 2015
From: supittma at redhat.com (Summers Pittman)
Date: Wed, 14 Jan 2015 08:35:55 -0500
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <552925103.9889778.1421223707494.JavaMail.zimbra@redhat.com>
References: <54B5439D.2040909@redhat.com>
	<659701591.9880791.1421222585163.JavaMail.zimbra@redhat.com>
	<552925103.9889778.1421223707494.JavaMail.zimbra@redhat.com>
Message-ID: <54B670BB.2080703@redhat.com>

On 01/14/2015 03:21 AM, Stian Thorgersen wrote:
> Maybe this is something that could be added to FreeOTP? That would be a good reason for folks to switch to Red Hat's over Google's ;)
Speaking of FreeOTP I've been meaning to finish up a PR which adds 
Android Wear support...
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 14 January, 2015 9:03:05 AM
>> Subject: Re: [keycloak-dev] Why do I have to enter the OTP?
>>
>> Look at YubiKey and FIDO U2F
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 13 January, 2015 5:11:09 PM
>>> Subject: [keycloak-dev] Why do I have to enter the OTP?
>>>
>>> Why does a user have to enter in the OTP generated by their mobile
>>> device?  Wouldn't it be cooler if the steps were:
>>>
>>> 1. Enter in username password in the browser
>>> 2. Browser blocks and wait for...
>>> 3. Press a button on your OTP iphone app
>>> 4. iphone app sends an HTTP message to Keycloak with username and
>>> generated OTP (in background)
>>> 5. Keycloak sees if a browser app is waiting for OTP verification, then
>>> verifies OTP if so.
>>> 6. Browser unblocks and lets user in.
>>>
>>> Now, the user doesn't ever have to enter the OTP (and mess it up like I
>>> do all the time).  They just need their mobile device.
>>>
>>>
>>>
>>> --
>>> 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


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.


From stian at redhat.com  Wed Jan 14 08:45:58 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 Jan 2015 08:45:58 -0500 (EST)
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
Message-ID: <853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>

Direct grants are expected to be a little bit slower in 1.1.x due to the requirement to persist more, but should certainly not be seconds.

Can you give some more details please? Including

* What DB are you using?
* Are you using mem, infinispan or jpa user session provider?
* Clustered?
* How many concurrent requests/users are you testing with?

Any more accurate performance stats would also be helpful

----- Original Message -----
> From: "Daniel Baxter" <daniel.baxter at cira.ca>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 January, 2015 9:23:42 PM
> Subject: [keycloak-dev] Slow Direct Grants API endpoint
> 
> 
> 
> Hi,
> 
> 
> 
> I am attempting to integrate Keycloak into an existing application to replace
> the homegrown user management system in place. We have a new project built
> from the ground up on Keycloak 1.0.4.Final which is exhibiting good
> performance. However this app that I am porting has a remoting component
> that connects to the server with bare username/password credentials over the
> EJB Remoting framework. I was hoping to use 1.1.0 (currently Beta2) which
> provides a DirectAccessGrantsLoginModule which does exactly what I want
> (turns username and password into a KeycloakPrincipal). However, the turn
> around time from Keycloak is on the order of several seconds.
> 
> 
> 
> I have used a bare REST client to execute the POSTs to both our 1.0.4
> Keycloak and 1.1.0 Keycloak instances and have noted an order of magnitude
> difference in getting a response. Is this a known issue (I cannot find
> anything in the public bugs/tasks list)? Or is this due to the Beta status
> leaving additional performance affecting logging or instrumentation in
> place?
> 
> 
> 
> Thanks,
> 
> 
> 
> Daniel
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From daniel.baxter at cira.ca  Wed Jan 14 09:01:17 2015
From: daniel.baxter at cira.ca (Daniel Baxter)
Date: Wed, 14 Jan 2015 14:01:17 +0000
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>
Message-ID: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>

I am working with our ops team to configure 1.1.x with the same level of hardware as our development 1.0.4 system (right now it is running locally on a XEON workstation with piles of RAM). 

Both are connected to postgres databases and I am the only person working on this portion of the project so it is just 1 user at a time right now for 1.1.x. I have tested the database connection and there is no real discernable performance irregularities for anything that runs against that database.

For Keycloak itself, it is mostly straight out of the box appliance install for both 1.0.4 and 1.1.x and it runs on a single machine for development use (I believe our prod deployment is/will be clustered). The performance I am seeing is timeable on a stop watch for 1.1 and near enough to instant for 1.0.4 (under 500 ms). Easily an order of magnitude. Given the response I got (regarding the unexpectedness of the slow behaviour) I want to make sure I have a completely fair comparison and am working to set up 1.1 on a dedicated development server to make the comparison completely fair.

- Daniel

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

Direct grants are expected to be a little bit slower in 1.1.x due to the requirement to persist more, but should certainly not be seconds.

Can you give some more details please? Including

* What DB are you using?
* Are you using mem, infinispan or jpa user session provider?
* Clustered?
* How many concurrent requests/users are you testing with?

Any more accurate performance stats would also be helpful

----- Original Message -----
> From: "Daniel Baxter" <daniel.baxter at cira.ca>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 12 January, 2015 9:23:42 PM
> Subject: [keycloak-dev] Slow Direct Grants API endpoint
> 
> 
> 
> Hi,
> 
> 
> 
> I am attempting to integrate Keycloak into an existing application to 
> replace the homegrown user management system in place. We have a new 
> project built from the ground up on Keycloak 1.0.4.Final which is 
> exhibiting good performance. However this app that I am porting has a 
> remoting component that connects to the server with bare 
> username/password credentials over the EJB Remoting framework. I was 
> hoping to use 1.1.0 (currently Beta2) which provides a 
> DirectAccessGrantsLoginModule which does exactly what I want (turns 
> username and password into a KeycloakPrincipal). However, the turn around time from Keycloak is on the order of several seconds.
> 
> 
> 
> I have used a bare REST client to execute the POSTs to both our 1.0.4 
> Keycloak and 1.1.0 Keycloak instances and have noted an order of 
> magnitude difference in getting a response. Is this a known issue (I 
> cannot find anything in the public bugs/tasks list)? Or is this due to 
> the Beta status leaving additional performance affecting logging or 
> instrumentation in place?
> 
> 
> 
> Thanks,
> 
> 
> 
> Daniel
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Jan 14 09:19:29 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 14 Jan 2015 09:19:29 -0500 (EST)
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>
Message-ID: <86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>

What user session provider are you using?

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

From daniel.baxter at cira.ca  Wed Jan 14 09:56:03 2015
From: daniel.baxter at cira.ca (Daniel Baxter)
Date: Wed, 14 Jan 2015 14:56:03 +0000
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>
	<86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>
Message-ID: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA11F7@EXCH-01.CORP.CIRA.CA>

Honestly I don't know how to check what is being used. I assume it would be whatever Keycloak Appliance defaults to. I checked with the guy who configured 1.0.4 for the other application and he doesn't know what we are using or how to configure it either. Sorry.

- Daniel

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

What user session provider are you using?

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


From bburke at redhat.com  Wed Jan 14 13:12:37 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 14 Jan 2015 13:12:37 -0500
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B61C96.3090707@kroehling.de>
References: <54B5439D.2040909@redhat.com> <54B61C96.3090707@kroehling.de>
Message-ID: <54B6B195.1070000@redhat.com>



On 1/14/2015 2:36 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/13/2015 05:11 PM, Bill Burke wrote:
>> Why does a user have to enter in the OTP generated by their mobile
>>   device?  Wouldn't it be cooler if the steps were:
>>
>> 1. Enter in username password in the browser 2. Browser blocks and
>> wait for... 3. Press a button on your OTP iphone app 4. iphone app
>> sends an HTTP message to Keycloak with username and generated OTP
>> (in background) 5. Keycloak sees if a browser app is waiting for
>> OTP verification, then verifies OTP if so.
>
> How do you ensure that this browser is the same as the real user, and
> not from an attacker?
>

The browser has correctly entered in a password.  There would be a 
timeout for the browser blocking/waiting for the background OTP transmit.


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

From bburke at redhat.com  Wed Jan 14 13:14:25 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 14 Jan 2015 13:14:25 -0500
Subject: [keycloak-dev] oauth vulnerabilities
In-Reply-To: <1027546757.9896136.1421224914461.JavaMail.zimbra@redhat.com>
References: <54ADDA0B.2060906@redhat.com> <54ADDE0F.4000700@redhat.com>
	<1027546757.9896136.1421224914461.JavaMail.zimbra@redhat.com>
Message-ID: <54B6B201.8060201@redhat.com>

I disagree.  Wildcard should be able to match multiple levels.  For 
complex sites it would get really tedious otherwise. (and not backward 
compatible for what we currently have).

On 1/14/2015 3:41 AM, Stian Thorgersen wrote:
> I agree we shouldn't allow relative redirect URLs.
>
> We should also improve our wildcard matching to only allow one level, for example:
>
>    http://www.site.com/a/*
>
> Should match:
>
>    http://www.site.com/a/page.html
>
> But not:
>
>    http://www.site.com/a/b/page.html
>
> We don't check the redirect_uri in the access token request either. I've created https://issues.jboss.org/browse/KEYCLOAK-957 for that.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 8 January, 2015 2:31:59 AM
>> Subject: Re: [keycloak-dev] oauth vulnerabilities
>>
>> Read this one, specifically that attack on github (you have to scroll
>> down a bit):
>>
>> http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html
>>
>> wildcard redirect uri patterns are pretty scary!
>>
>> On 1/7/2015 8:14 PM, Bill Burke wrote:
>>> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html
>>>
>>> I think we're pretty good, the ones I worry about is relative urls in
>>> redirect URI checks i.e.
>>>
>>> "http://cloud.com/provisioned/good-site/../hacker-site"
>>>
>>> I'll log a bug for this if you agree that relative redirect URLs
>>> shouldn't be allowed. (Those containing "." and "..")
>>>
>>> Another really dangerous thing that we do is have full-scope-allowed set
>>> to true by default.  If a rogue client gets registered, they pretty much
>>> have access to every single application the user can access with all of
>>> their privileges.
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From mposolda at redhat.com  Thu Jan 15 01:46:43 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 15 Jan 2015 07:46:43 +0100
Subject: [keycloak-dev] oauth vulnerabilities
In-Reply-To: <54B6B201.8060201@redhat.com>
References: <54ADDA0B.2060906@redhat.com>
	<54ADDE0F.4000700@redhat.com>	<1027546757.9896136.1421224914461.JavaMail.zimbra@redhat.com>
	<54B6B201.8060201@redhat.com>
Message-ID: <54B76253.80400@redhat.com>

+1 for support multiple levels.

One thing I am not sure is disable "Full scope allowed" by default. 
Disabling it will improve security a bit, but it's also not backward 
compatible. And I reckon if we disable it, there might be bunch of 
questions on keycloak-user like "My rest applications, which worked on 
1.0 don't work on anymore" ;-)

Marek

On 14.1.2015 19:14, Bill Burke wrote:
> I disagree.  Wildcard should be able to match multiple levels.  For
> complex sites it would get really tedious otherwise. (and not backward
> compatible for what we currently have).
>
> On 1/14/2015 3:41 AM, Stian Thorgersen wrote:
>> I agree we shouldn't allow relative redirect URLs.
>>
>> We should also improve our wildcard matching to only allow one level, for example:
>>
>>     http://www.site.com/a/*
>>
>> Should match:
>>
>>     http://www.site.com/a/page.html
>>
>> But not:
>>
>>     http://www.site.com/a/b/page.html
>>
>> We don't check the redirect_uri in the access token request either. I've created https://issues.jboss.org/browse/KEYCLOAK-957 for that.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 8 January, 2015 2:31:59 AM
>>> Subject: Re: [keycloak-dev] oauth vulnerabilities
>>>
>>> Read this one, specifically that attack on github (you have to scroll
>>> down a bit):
>>>
>>> http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html
>>>
>>> wildcard redirect uri patterns are pretty scary!
>>>
>>> On 1/7/2015 8:14 PM, Bill Burke wrote:
>>>> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html
>>>>
>>>> I think we're pretty good, the ones I worry about is relative urls in
>>>> redirect URI checks i.e.
>>>>
>>>> "http://cloud.com/provisioned/good-site/../hacker-site"
>>>>
>>>> I'll log a bug for this if you agree that relative redirect URLs
>>>> shouldn't be allowed. (Those containing "." and "..")
>>>>
>>>> Another really dangerous thing that we do is have full-scope-allowed set
>>>> to true by default.  If a rogue client gets registered, they pretty much
>>>> have access to every single application the user can access with all of
>>>> their privileges.
>>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>


From stian at redhat.com  Thu Jan 15 02:43:50 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jan 2015 02:43:50 -0500 (EST)
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B6B195.1070000@redhat.com>
References: <54B5439D.2040909@redhat.com> <54B61C96.3090707@kroehling.de>
	<54B6B195.1070000@redhat.com>
Message-ID: <923134612.10626395.1421307830970.JavaMail.zimbra@redhat.com>

I think we'd need some mechanism in place so the user knows he initiated the request. Keycloak could for example display a random phrase, for example "RED SHOE" which would also be displayed on the mobile. Banks in Norway use a similar mechanism.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 14 January, 2015 7:12:37 PM
> Subject: Re: [keycloak-dev] Why do I have to enter the OTP?
> 
> 
> 
> On 1/14/2015 2:36 AM, Juraci Paix?o Kr?hling wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 01/13/2015 05:11 PM, Bill Burke wrote:
> >> Why does a user have to enter in the OTP generated by their mobile
> >>   device?  Wouldn't it be cooler if the steps were:
> >>
> >> 1. Enter in username password in the browser 2. Browser blocks and
> >> wait for... 3. Press a button on your OTP iphone app 4. iphone app
> >> sends an HTTP message to Keycloak with username and generated OTP
> >> (in background) 5. Keycloak sees if a browser app is waiting for
> >> OTP verification, then verifies OTP if so.
> >
> > How do you ensure that this browser is the same as the real user, and
> > not from an attacker?
> >
> 
> The browser has correctly entered in a password.  There would be a
> timeout for the browser blocking/waiting for the background OTP transmit.
> 
> 
> --
> 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 juraci at kroehling.de  Thu Jan 15 02:48:33 2015
From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Thu, 15 Jan 2015 08:48:33 +0100
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <923134612.10626395.1421307830970.JavaMail.zimbra@redhat.com>
References: <54B5439D.2040909@redhat.com>
	<54B61C96.3090707@kroehling.de>	<54B6B195.1070000@redhat.com>
	<923134612.10626395.1421307830970.JavaMail.zimbra@redhat.com>
Message-ID: <54B770D1.4080306@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/15/2015 08:43 AM, Stian Thorgersen wrote:
> I think we'd need some mechanism in place so the user knows he
> initiated the request. Keycloak could for example display a random
> phrase, for example "RED SHOE" which would also be displayed on the
> mobile. Banks in Norway use a similar mechanism.

I thought about something similar: a text on a box with a random
background color. Both the text and the color should match what is
seen in the browser. The user is probably never going to check the
text, but the color might get the user's attention.

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUt3DRAAoJEDnJtskdmzLMqTkH/iSCGIAIr3HQ49oUgwJ3KX4F
O4VbeCzX0AVX2i2wknHczpDUrmmytLVzHpxLtpa31BeK4V2jsyPkWmQBdwP3F5gP
pbuC3l7aXv7s9NvyQ1gIA01wRKnqBasalQoonhZ2yx+YMjEpm/opuniIZ5cD1Glr
fvvT8hFeUcGzLPesKb+3cGYR4H3PterRPjcD2RRR4f1rNsXXV/moswMYChamdmRd
XNEux3MnNmFgOniV9bsBzDC6dEhYXICOrlXR9HATWSmGdGsEElANY3v2o494oUq0
sGFcVMsujSjWACW6NTWfiTrSJgh+9aX9WDjFW/UkxZB3m4ufJJ82b3zO6IPIITA=
=eI+A
-----END PGP SIGNATURE-----

From stian at redhat.com  Thu Jan 15 02:53:50 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jan 2015 02:53:50 -0500 (EST)
Subject: [keycloak-dev] Why do I have to enter the OTP?
In-Reply-To: <54B770D1.4080306@kroehling.de>
References: <54B5439D.2040909@redhat.com> <54B61C96.3090707@kroehling.de>
	<54B6B195.1070000@redhat.com>
	<923134612.10626395.1421307830970.JavaMail.zimbra@redhat.com>
	<54B770D1.4080306@kroehling.de>
Message-ID: <1515167345.10628827.1421308430203.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Juraci Paix?o Kr?hling" <juraci at kroehling.de>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 15 January, 2015 8:48:33 AM
> Subject: Re: [keycloak-dev] Why do I have to enter the OTP?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/15/2015 08:43 AM, Stian Thorgersen wrote:
> > I think we'd need some mechanism in place so the user knows he
> > initiated the request. Keycloak could for example display a random
> > phrase, for example "RED SHOE" which would also be displayed on the
> > mobile. Banks in Norway use a similar mechanism.
> 
> I thought about something similar: a text on a box with a random
> background color. Both the text and the color should match what is
> seen in the browser. The user is probably never going to check the
> text, but the color might get the user's attention.

Actually I think the two words work well, as they are always an adjective followed by a noun they are easy to remember.

Not sure about color for a few reasons:

- It'll look horrible
- People filter out backgrounds
- Color mismatch between desktop and mobile screens 

> 
> - - Juca.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJUt3DRAAoJEDnJtskdmzLMqTkH/iSCGIAIr3HQ49oUgwJ3KX4F
> O4VbeCzX0AVX2i2wknHczpDUrmmytLVzHpxLtpa31BeK4V2jsyPkWmQBdwP3F5gP
> pbuC3l7aXv7s9NvyQ1gIA01wRKnqBasalQoonhZ2yx+YMjEpm/opuniIZ5cD1Glr
> fvvT8hFeUcGzLPesKb+3cGYR4H3PterRPjcD2RRR4f1rNsXXV/moswMYChamdmRd
> XNEux3MnNmFgOniV9bsBzDC6dEhYXICOrlXR9HATWSmGdGsEElANY3v2o494oUq0
> sGFcVMsujSjWACW6NTWfiTrSJgh+9aX9WDjFW/UkxZB3m4ufJJ82b3zO6IPIITA=
> =eI+A
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From stian at redhat.com  Thu Jan 15 07:00:25 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jan 2015 07:00:25 -0500 (EST)
Subject: [keycloak-dev] Direct grant API enable/disable on per-app instead
	of realm
In-Reply-To: <73419070.10759636.1421323078146.JavaMail.zimbra@redhat.com>
Message-ID: <488356343.10760306.1421323225531.JavaMail.zimbra@redhat.com>

I propose we move the "Direct Grant API" enable/disable from the realm and add it to applications/clients instead. This allows greater control over what is exposed using the direct grant api.

From stian at redhat.com  Thu Jan 15 07:36:56 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jan 2015 07:36:56 -0500 (EST)
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA11F7@EXCH-01.CORP.CIRA.CA>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>
	<86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11F7@EXCH-01.CORP.CIRA.CA>
Message-ID: <1931160200.10779706.1421325416961.JavaMail.zimbra@redhat.com>

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

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


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

From bburke at redhat.com  Thu Jan 15 08:39:22 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 15 Jan 2015 08:39:22 -0500
Subject: [keycloak-dev] oauth vulnerabilities
In-Reply-To: <54B76253.80400@redhat.com>
References: <54ADDA0B.2060906@redhat.com>
	<54ADDE0F.4000700@redhat.com>	<1027546757.9896136.1421224914461.JavaMail.zimbra@redhat.com>
	<54B6B201.8060201@redhat.com> <54B76253.80400@redhat.com>
Message-ID: <54B7C30A.6080401@redhat.com>

Yeah, "Full scope allowed" by default is a security hole for deployments 
that may have rogue clients, but we had *so* many questions on scope 
mappings with users not being able to get things to work, so it has to 
stay on by default, IMO.

On 1/15/2015 1:46 AM, Marek Posolda wrote:
> +1 for support multiple levels.
>
> One thing I am not sure is disable "Full scope allowed" by default.
> Disabling it will improve security a bit, but it's also not backward
> compatible. And I reckon if we disable it, there might be bunch of
> questions on keycloak-user like "My rest applications, which worked on
> 1.0 don't work on anymore" ;-)
>
> Marek
>
> On 14.1.2015 19:14, Bill Burke wrote:
>> I disagree.  Wildcard should be able to match multiple levels.  For
>> complex sites it would get really tedious otherwise. (and not backward
>> compatible for what we currently have).
>>
>> On 1/14/2015 3:41 AM, Stian Thorgersen wrote:
>>> I agree we shouldn't allow relative redirect URLs.
>>>
>>> We should also improve our wildcard matching to only allow one level,
>>> for example:
>>>
>>>     http://www.site.com/a/*
>>>
>>> Should match:
>>>
>>>     http://www.site.com/a/page.html
>>>
>>> But not:
>>>
>>>     http://www.site.com/a/b/page.html
>>>
>>> We don't check the redirect_uri in the access token request either.
>>> I've created https://issues.jboss.org/browse/KEYCLOAK-957 for that.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 8 January, 2015 2:31:59 AM
>>>> Subject: Re: [keycloak-dev] oauth vulnerabilities
>>>>
>>>> Read this one, specifically that attack on github (you have to scroll
>>>> down a bit):
>>>>
>>>> http://intothesymmetry.blogspot.ch/2014/10/beware-what-you-click.html
>>>>
>>>> wildcard redirect uri patterns are pretty scary!
>>>>
>>>> On 1/7/2015 8:14 PM, Bill Burke wrote:
>>>>> http://intothesymmetry.blogspot.ch/2015/01/top-5-oauth-2-implementation.html
>>>>>
>>>>>
>>>>> I think we're pretty good, the ones I worry about is relative urls in
>>>>> redirect URI checks i.e.
>>>>>
>>>>> "http://cloud.com/provisioned/good-site/../hacker-site"
>>>>>
>>>>> I'll log a bug for this if you agree that relative redirect URLs
>>>>> shouldn't be allowed. (Those containing "." and "..")
>>>>>
>>>>> Another really dangerous thing that we do is have
>>>>> full-scope-allowed set
>>>>> to true by default.  If a rogue client gets registered, they pretty
>>>>> much
>>>>> have access to every single application the user can access with
>>>>> all of
>>>>> their privileges.
>>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>

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

From bburke at redhat.com  Thu Jan 15 10:18:55 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 15 Jan 2015 10:18:55 -0500
Subject: [keycloak-dev] Direct grant API enable/disable on per-app
 instead of realm
In-Reply-To: <488356343.10760306.1421323225531.JavaMail.zimbra@redhat.com>
References: <488356343.10760306.1421323225531.JavaMail.zimbra@redhat.com>
Message-ID: <54B7DA5F.8070109@redhat.com>

I don't know...Once you have one public client that supports direct 
grants with a large enough scope, there's your attack vector.


On 1/15/2015 7:00 AM, Stian Thorgersen wrote:
> I propose we move the "Direct Grant API" enable/disable from the realm and add it to applications/clients instead. This allows greater control over what is exposed using the direct grant api.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Thu Jan 15 10:38:15 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 15 Jan 2015 10:38:15 -0500 (EST)
Subject: [keycloak-dev] Direct grant API enable/disable on per-app
 instead of realm
In-Reply-To: <54B7DA5F.8070109@redhat.com>
References: <488356343.10760306.1421323225531.JavaMail.zimbra@redhat.com>
	<54B7DA5F.8070109@redhat.com>
Message-ID: <1192534252.10933598.1421336295727.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 15 January, 2015 4:18:55 PM
> Subject: Re: [keycloak-dev] Direct grant API enable/disable on per-app instead of realm
> 
> I don't know...Once you have one public client that supports direct
> grants with a large enough scope, there's your attack vector.

Well, sure if you enable if for a public client with the full scope it doesn't make much difference. But, currently you can't limit it at all other than turning it off completely.

Also, another thing is that currently we require a redirect-uri to be registered for an app, but that shouldn't be required if an app only uses the direct grant.

> 
> 
> On 1/15/2015 7:00 AM, Stian Thorgersen wrote:
> > I propose we move the "Direct Grant API" enable/disable from the realm and
> > add it to applications/clients instead. This allows greater control over
> > what is exposed using the direct grant api.
> > _______________________________________________
> > 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  Thu Jan 15 11:46:11 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 15 Jan 2015 11:46:11 -0500 (EST)
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <1842817010.10023449.1421339871977.JavaMail.zimbra@redhat.com>
Message-ID: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>

Bill,

    Is the work you are doing for claims considering the respective sections in OpenID Connect specification ? To be more specific, http://openid.net/specs/openid-connect-core-1_0.html#Claims.

    Depending on what you are doing, I think I would need to wait you finish in order to full support what is expected from the UserInfo endpoint. Meanwhile, I'm already doing everything that is necessary to get the endpoint up and running with a basic interoperability based on the default scope values used to request claims (profile, email, address, phone).

    Btw, are you planning to configure any type of configuration in order to setup the privacy of certain claims ?

Regards.
Pedro Igor

From psilva at redhat.com  Thu Jan 15 12:40:41 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 15 Jan 2015 12:40:41 -0500 (EST)
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
References: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
Message-ID: <585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, January 15, 2015 2:46:11 PM
> Subject: KEYCLOAK-884 - UserInfo Endpoint
> 
> Bill,
> 
>     Is the work you are doing for claims considering the respective sections
>     in OpenID Connect specification ? To be more specific,
>     http://openid.net/specs/openid-connect-core-1_0.html#Claims.
> 
>     Depending on what you are doing, I think I would need to wait you finish
>     in order to full support what is expected from the UserInfo endpoint.
>     Meanwhile, I'm already doing everything that is necessary to get the
>     endpoint up and running with a basic interoperability based on the
>     default scope values used to request claims (profile, email, address,
>     phone).
> 
>     Btw, are you planning to configure any type of configuration in order to
>     setup the privacy of certain claims ?

Forget about it. Just noticed you already have support for that.

> 
> Regards.
> Pedro Igor

From bburke at redhat.com  Thu Jan 15 14:07:22 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 15 Jan 2015 14:07:22 -0500
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>
References: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
	<585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>
Message-ID: <54B80FEA.8060704@redhat.com>



On 1/15/2015 12:40 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, January 15, 2015 2:46:11 PM
>> Subject: KEYCLOAK-884 - UserInfo Endpoint
>>
>> Bill,
>>
>>      Is the work you are doing for claims considering the respective sections
>>      in OpenID Connect specification ? To be more specific,
>>      http://openid.net/specs/openid-connect-core-1_0.html#Claims.
>>
>>      Depending on what you are doing, I think I would need to wait you finish
>>      in order to full support what is expected from the UserInfo endpoint.
>>      Meanwhile, I'm already doing everything that is necessary to get the
>>      endpoint up and running with a basic interoperability based on the
>>      default scope values used to request claims (profile, email, address,
>>      phone).
>>
>>      Btw, are you planning to configure any type of configuration in order to
>>      setup the privacy of certain claims ?
>
> Forget about it. Just noticed you already have support for that.
>

Nothing beyond a few claims though.  Can't enter in address, phone, etc...

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

From mposolda at redhat.com  Thu Jan 15 14:58:44 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 15 Jan 2015 20:58:44 +0100
Subject: [keycloak-dev] Fuse adapter added
Message-ID: <54B81BF4.1060903@redhat.com>

I've finally pushed fuse adapter to both master and 1.1 branch including 
documentation and demo example with instructions on how to have it 
running on karaf/fuse. Finally I managed to secure the web based 
applications on Fuse with our Jetty8 adapter. The main pitfall was about 
properly inject KeycloakJettyAuthenticator to the Jetty engine for 
various kind of apps (classic WAR, OSGI deployed servlet, Apache CXF, 
Apache Camel).

There is many changed files in repo now, however it's mainly about 
packaging, examples and distribution. No changes in the core code 
despite some minor change in jetty adapter. Few things:

* Added OSGI headers to some of our maven modules, which are supposed to 
be running as OSGI bundles in fuse/karaf. It's keycloak-core, 
keycloak-adapter-core, keycloak-jetty adapters etc.

* Renamed java package in jetty-core module to 
"org.keycloak.adapters.jetty.core" . OSGI doesn't like when there are 2 
jars having same package when one of them depend on the other. I've 
finally change the package just in jetty-core as there are just internal 
classes. Docs doesn't need to be changed and adapter is backwards 
compatible as name of authenticator class is still 
"org.keycloak.adapters.jetty.KeycloakJettyAuthenticator"

* Changes in "distribution/osgi" related to OSGI bundling to allow have 
adapter and easily install it in fuse/karaf

* Added "fuse" example with couple of sub-modules . This is slightly 
modified version of our demo, which is supposed to be deployed on 
karaf/fuse. This brings some Apache dependencies like cxf, camel etc. 
but all of them are supposed to be in maven central.

Hope I did not break anything and you all are still able to build 
keycloak:-)
Let me know if you have more points, suggestions.

Marek

From stian at redhat.com  Fri Jan 16 06:57:36 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 Jan 2015 06:57:36 -0500 (EST)
Subject: [keycloak-dev] What is ServerVersionResource used for?
In-Reply-To: <384278674.11409277.1421409394747.JavaMail.zimbra@redhat.com>
Message-ID: <1721353478.11409603.1421409456473.JavaMail.zimbra@redhat.com>

I'm curious about why we have ServerVersionResource? What is it used for?

Having a public endpoint that shows the version of the server makes it easier for script kiddies to scan for servers of a specific version, which can then be targeted for known exploits.

From psilva at redhat.com  Fri Jan 16 08:30:05 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 16 Jan 2015 08:30:05 -0500 (EST)
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <54B80FEA.8060704@redhat.com>
References: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
	<585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>
	<54B80FEA.8060704@redhat.com>
Message-ID: <106136572.10561573.1421415005955.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, January 15, 2015 5:07:22 PM
> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> 
> 
> 
> On 1/15/2015 12:40 PM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Thursday, January 15, 2015 2:46:11 PM
> >> Subject: KEYCLOAK-884 - UserInfo Endpoint
> >>
> >> Bill,
> >>
> >>      Is the work you are doing for claims considering the respective
> >>      sections
> >>      in OpenID Connect specification ? To be more specific,
> >>      http://openid.net/specs/openid-connect-core-1_0.html#Claims.
> >>
> >>      Depending on what you are doing, I think I would need to wait you
> >>      finish
> >>      in order to full support what is expected from the UserInfo endpoint.
> >>      Meanwhile, I'm already doing everything that is necessary to get the
> >>      endpoint up and running with a basic interoperability based on the
> >>      default scope values used to request claims (profile, email, address,
> >>      phone).
> >>
> >>      Btw, are you planning to configure any type of configuration in order
> >>      to
> >>      setup the privacy of certain claims ?
> >
> > Forget about it. Just noticed you already have support for that.
> >
> 
> Nothing beyond a few claims though.  Can't enter in address, phone, etc...

I've submitted a PR for this issue. There are some changes to IDToken type that would like to share and discuss.

Today, user claims are strongly tied with the IDToken type. They are there as properties of the type itself. From a token perspective, that is how they are represented but from an internal perspective I think we can improve it a little bit by introducing a specific type for user claims.

IMO, a best design is to extract those specific claims from IDToken type and get them into a specific UserClaimSet, which also helps to avoid code duplication when claims are needed in different places. Just like we need it in UserInfo.

That allow us to better represent/manage user claims internally and keep things more in sync with the specs, without break anything from a token representation or functionality perspective.

Any thoughts ?

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

From ssilvert at redhat.com  Fri Jan 16 08:35:01 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 Jan 2015 08:35:01 -0500
Subject: [keycloak-dev] Location of User Federation Provider jar in Keycloak
	1.1 Beta-2
In-Reply-To: <1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>
	<54B7BC24.5070501@redhat.com>
	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>
	<54B821D4.8040202@redhat.com>
	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
Message-ID: <54B91385.9070500@redhat.com>

Moved to dev list.  Comments inline.
On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-user at lists.jboss.org
>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
>>
>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>> How is a provider added using the CLI? I can't find any examples on that.
>> In the doc there is a step-by-step example of how to do it.  See section
>> 3.4.2.2.
>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
> That example uses the CLI GUI, we need one that uses plain CLI
Plain CLI is harder in this case.  CLI GUI lets you browse for the file 
you need.   Overall, plain CLI is a lot more error prone.

If you do this once in CLI GUI then you will generate the CLI command 
that you can cut and paste into plain CLI or a script.  But if you want, 
I can include an example of that command.
>
> There's also another issue with this approach, which I didn't stress enough last time around, it requires the server to be running to add providers. That makes it much harder to for example create a Docker cartridge that includes some custom providers.
Perhaps we just need to document the fact that you can still explode the 
WAR and do it the old way?
>
>>> Also, there are still several references in the docs and examples that uses
>>> the old approach of copying to WEB-INF/lib.
>>>
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-user at lists.jboss.org
>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>> Keycloak 1.1 Beta-2
>>>>
>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>
>>>> See
>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>
>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I created a custom User Federation Provider and deployed it as per the
>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it appears
>>>> that the location of Keycloak war in Wildfly has changed in 1.1 Beta-2
>>>> version and it is no longer inflated. Can someone suggest where exactly I
>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>
>>>> Thanks,
>>>> Raghu
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>


From ssilvert at redhat.com  Fri Jan 16 08:36:15 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 Jan 2015 08:36:15 -0500
Subject: [keycloak-dev] Location of User Federation Provider jar in Keycloak
	1.1 Beta-2
In-Reply-To: <54B903E1.20304@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B7BC24.5070501@redhat.com>	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>	<54B821D4.8040202@redhat.com>
	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
	<54B903E1.20304@redhat.com>
Message-ID: <54B913CF.4000806@redhat.com>

Moved to dev list.
On 1/16/2015 7:28 AM, Marek Posolda wrote:
> Figured out that our "war-dist" still contains auth-server.war in 
> "standalone/deployments" . Appliance dist doesn't have it. This is not 
> expected right? The chapter 3.1 and 3.2 both mentions auth-server.war 
> in deployments folder btv (which is not true at least for appliance 
> dist now).
The WAR dist doesn't contain the subsystem.  So it has to work the old way.

I think we need to come to a final decision about supporting the auth 
server on other platforms, which is the only reason for the WAR dist to 
still exist.
>
> Found out that with the "war-dist" and auth-server.war deployed in 
> standalone/deployments I can normally copy the provider jar to 
> standalone/deployments/auth-server.war/WEB-INF/lib and it works:-)
>
> Marek
>
> On 16.1.2015 08:19, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-user at lists.jboss.org
>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>>> Subject: Re: [keycloak-user] Location of User Federation Provider 
>>> jar in Keycloak 1.1 Beta-2
>>>
>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>>> How is a provider added using the CLI? I can't find any examples on 
>>>> that.
>>> In the doc there is a step-by-step example of how to do it. See section
>>> 3.4.2.2.
>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350 
>>>
>> That example uses the CLI GUI, we need one that uses plain CLI
>>
>> There's also another issue with this approach, which I didn't stress 
>> enough last time around, it requires the server to be running to add 
>> providers. That makes it much harder to for example create a Docker 
>> cartridge that includes some custom providers.
>>
>>>> Also, there are still several references in the docs and examples 
>>>> that uses
>>>> the old approach of copying to WEB-INF/lib.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: keycloak-user at lists.jboss.org
>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider 
>>>>> jar in
>>>>> Keycloak 1.1 Beta-2
>>>>>
>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>>
>>>>> See
>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350 
>>>>>
>>>>>
>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I created a custom User Federation Provider and deployed it as per 
>>>>> the
>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it 
>>>>> appears
>>>>> that the location of Keycloak war in Wildfly has changed in 1.1 
>>>>> Beta-2
>>>>> version and it is no longer inflated. Can someone suggest where 
>>>>> exactly I
>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>>
>>>>> Thanks,
>>>>> Raghu
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>


From ssilvert at redhat.com  Fri Jan 16 08:40:59 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 Jan 2015 08:40:59 -0500
Subject: [keycloak-dev] Location of User Federation Provider jar in
 Keycloak 1.1 Beta-2
In-Reply-To: <54B913CF.4000806@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B7BC24.5070501@redhat.com>	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>	<54B821D4.8040202@redhat.com>
	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
	<54B903E1.20304@redhat.com> <54B913CF.4000806@redhat.com>
Message-ID: <54B914EB.8030803@redhat.com>

On 1/16/2015 8:36 AM, Stan Silvert wrote:
> Moved to dev list.
> On 1/16/2015 7:28 AM, Marek Posolda wrote:
>> Figured out that our "war-dist" still contains auth-server.war in
>> "standalone/deployments" . Appliance dist doesn't have it. This is not
>> expected right? The chapter 3.1 and 3.2 both mentions auth-server.war
>> in deployments folder btv (which is not true at least for appliance
>> dist now).
> The WAR dist doesn't contain the subsystem.  So it has to work the old way.
>
> I think we need to come to a final decision about supporting the auth
> server on other platforms, which is the only reason for the WAR dist to
> still exist.
Stain>>>

If we want to be the OOTB solution for other JBoss projects it has to be possible to embed Keycloak into their solutions. I think that means we'll have to support Tomcat, Jetty, etc runtimes.

>> Found out that with the "war-dist" and auth-server.war deployed in
>> standalone/deployments I can normally copy the provider jar to
>> standalone/deployments/auth-server.war/WEB-INF/lib and it works:-)
>>
>> Marek
>>
>> On 16.1.2015 08:19, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-user at lists.jboss.org
>>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>>>> Subject: Re: [keycloak-user] Location of User Federation Provider
>>>> jar in Keycloak 1.1 Beta-2
>>>>
>>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>>>> How is a provider added using the CLI? I can't find any examples on
>>>>> that.
>>>> In the doc there is a step-by-step example of how to do it. See section
>>>> 3.4.2.2.
>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>
>>> That example uses the CLI GUI, we need one that uses plain CLI
>>>
>>> There's also another issue with this approach, which I didn't stress
>>> enough last time around, it requires the server to be running to add
>>> providers. That makes it much harder to for example create a Docker
>>> cartridge that includes some custom providers.
>>>
>>>>> Also, there are still several references in the docs and examples
>>>>> that uses
>>>>> the old approach of copying to WEB-INF/lib.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>> To: keycloak-user at lists.jboss.org
>>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider
>>>>>> jar in
>>>>>> Keycloak 1.1 Beta-2
>>>>>>
>>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>>>
>>>>>> See
>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>>>
>>>>>>
>>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I created a custom User Federation Provider and deployed it as per
>>>>>> the
>>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it
>>>>>> appears
>>>>>> that the location of Keycloak war in Wildfly has changed in 1.1
>>>>>> Beta-2
>>>>>> version and it is no longer inflated. Can someone suggest where
>>>>>> exactly I
>>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>>>
>>>>>> Thanks,
>>>>>> Raghu
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri Jan 16 09:04:54 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Jan 2015 09:04:54 -0500
Subject: [keycloak-dev] What is ServerVersionResource used for?
In-Reply-To: <1721353478.11409603.1421409456473.JavaMail.zimbra@redhat.com>
References: <1721353478.11409603.1421409456473.JavaMail.zimbra@redhat.com>
Message-ID: <54B91A86.6090201@redhat.com>

Helps with versioning for clients that are interacting with semi-public 
auth servers.  This is no different than a web server sending that it is 
"Apache" or "IIS" or "JBoss Web" or "Tomcat".

Script kiddies will run scripts to figure out the version anyways.  You 
really aren't slowing them down much by removing the ServerVersionResource

On 1/16/2015 6:57 AM, Stian Thorgersen wrote:
> I'm curious about why we have ServerVersionResource? What is it used for?
>
> Having a public endpoint that shows the version of the server makes it easier for script kiddies to scan for servers of a specific version, which can then be targeted for known exploits.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Fri Jan 16 09:07:10 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 Jan 2015 09:07:10 -0500 (EST)
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <106136572.10561573.1421415005955.JavaMail.zimbra@redhat.com>
References: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
	<585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>
	<54B80FEA.8060704@redhat.com>
	<106136572.10561573.1421415005955.JavaMail.zimbra@redhat.com>
Message-ID: <1597917021.11473783.1421417230594.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 January, 2015 2:30:05 PM
> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, January 15, 2015 5:07:22 PM
> > Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> > 
> > 
> > 
> > On 1/15/2015 12:40 PM, Pedro Igor Silva wrote:
> > > ----- Original Message -----
> > >> From: "Pedro Igor Silva" <psilva at redhat.com>
> > >> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >> Sent: Thursday, January 15, 2015 2:46:11 PM
> > >> Subject: KEYCLOAK-884 - UserInfo Endpoint
> > >>
> > >> Bill,
> > >>
> > >>      Is the work you are doing for claims considering the respective
> > >>      sections
> > >>      in OpenID Connect specification ? To be more specific,
> > >>      http://openid.net/specs/openid-connect-core-1_0.html#Claims.
> > >>
> > >>      Depending on what you are doing, I think I would need to wait you
> > >>      finish
> > >>      in order to full support what is expected from the UserInfo
> > >>      endpoint.
> > >>      Meanwhile, I'm already doing everything that is necessary to get
> > >>      the
> > >>      endpoint up and running with a basic interoperability based on the
> > >>      default scope values used to request claims (profile, email,
> > >>      address,
> > >>      phone).
> > >>
> > >>      Btw, are you planning to configure any type of configuration in
> > >>      order
> > >>      to
> > >>      setup the privacy of certain claims ?
> > >
> > > Forget about it. Just noticed you already have support for that.
> > >
> > 
> > Nothing beyond a few claims though.  Can't enter in address, phone, etc...
> 
> I've submitted a PR for this issue. There are some changes to IDToken type
> that would like to share and discuss.
> 
> Today, user claims are strongly tied with the IDToken type. They are there as
> properties of the type itself. From a token perspective, that is how they
> are represented but from an internal perspective I think we can improve it a
> little bit by introducing a specific type for user claims.
> 
> IMO, a best design is to extract those specific claims from IDToken type and
> get them into a specific UserClaimSet, which also helps to avoid code
> duplication when claims are needed in different places. Just like we need it
> in UserInfo.
> 
> That allow us to better represent/manage user claims internally and keep
> things more in sync with the specs, without break anything from a token
> representation or functionality perspective.

I'm not convinced about this. Other than IDToken and UserInfo endpoint I can't see any uses for this.

Also, I reckon this will change a fair bit by introducing custom user profiles. Internally I reckon we'll be using user profiles, not claim-set.

> 
> Any thoughts ?
> 
> > 
> > --
> > 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 ssilvert at redhat.com  Fri Jan 16 09:20:18 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 Jan 2015 09:20:18 -0500
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>
	<54B7BC24.5070501@redhat.com>
	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>
	<54B821D4.8040202@redhat.com>
	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
	<54B90E74.9040704@redhat.com>
	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
Message-ID: <54B91E22.4060808@redhat.com>

On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down to this issue. I should have raised it before, but it completely slipped my mind :(
We did talk about this at great length before.   I tried and tried to 
preserve the "drop it in the file system" approach.  It just plain won't 
work for domains.
>
> IMO we need:
>
> 1. A usable way to deploy a provider without using the CLI GUI
> 2. Ideally be able to deploy a provider with an offline server
We have 5 ways to add a provider:
1. CLI
2. CLI GUI
3. CLI script
4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
5. Use the war dist and do it the old way.

Why are these not sufficient?
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-user at lists.jboss.org
>> Sent: Friday, 16 January, 2015 2:13:24 PM
>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
>>
>> On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-user at lists.jboss.org
>>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>> Keycloak 1.1 Beta-2
>>>>
>>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>>>> How is a provider added using the CLI? I can't find any examples on that.
>>>> In the doc there is a step-by-step example of how to do it.  See section
>>>> 3.4.2.2.
>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>> That example uses the CLI GUI, we need one that uses plain CLI
>> Plain CLI is harder in this case.  CLI GUI lets you browse for the file
>> you need.   Overall, plain CLI is a lot more error prone.
>>
>> If you do this once in CLI GUI then you will generate the CLI command
>> that you can cut and paste into plain CLI or a script.  But if you want,
>> I can include an example of that command.
>>> There's also another issue with this approach, which I didn't stress enough
>>> last time around, it requires the server to be running to add providers.
>>> That makes it much harder to for example create a Docker cartridge that
>>> includes some custom providers.
>> Perhaps we just need to document the fact that you can still explode the
>> WAR and do it the old way?
>>>>> Also, there are still several references in the docs and examples that
>>>>> uses
>>>>> the old approach of copying to WEB-INF/lib.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>> To: keycloak-user at lists.jboss.org
>>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>>>> Keycloak 1.1 Beta-2
>>>>>>
>>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>>>
>>>>>> See
>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>>>
>>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I created a custom User Federation Provider and deployed it as per the
>>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it appears
>>>>>> that the location of Keycloak war in Wildfly has changed in 1.1 Beta-2
>>>>>> version and it is no longer inflated. Can someone suggest where exactly
>>>>>> I
>>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>>>
>>>>>> Thanks,
>>>>>> Raghu
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>


From bburke at redhat.com  Fri Jan 16 09:33:38 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Jan 2015 09:33:38 -0500
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <1597917021.11473783.1421417230594.JavaMail.zimbra@redhat.com>
References: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
	<585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>
	<54B80FEA.8060704@redhat.com>
	<106136572.10561573.1421415005955.JavaMail.zimbra@redhat.com>
	<1597917021.11473783.1421417230594.JavaMail.zimbra@redhat.com>
Message-ID: <54B92142.7010407@redhat.com>



On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 16 January, 2015 2:30:05 PM
>> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, January 15, 2015 5:07:22 PM
>>> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
>>>
>>>
>>>
>>> On 1/15/2015 12:40 PM, Pedro Igor Silva wrote:
>>>> ----- Original Message -----
>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Thursday, January 15, 2015 2:46:11 PM
>>>>> Subject: KEYCLOAK-884 - UserInfo Endpoint
>>>>>
>>>>> Bill,
>>>>>
>>>>>       Is the work you are doing for claims considering the respective
>>>>>       sections
>>>>>       in OpenID Connect specification ? To be more specific,
>>>>>       http://openid.net/specs/openid-connect-core-1_0.html#Claims.
>>>>>
>>>>>       Depending on what you are doing, I think I would need to wait you
>>>>>       finish
>>>>>       in order to full support what is expected from the UserInfo
>>>>>       endpoint.
>>>>>       Meanwhile, I'm already doing everything that is necessary to get
>>>>>       the
>>>>>       endpoint up and running with a basic interoperability based on the
>>>>>       default scope values used to request claims (profile, email,
>>>>>       address,
>>>>>       phone).
>>>>>
>>>>>       Btw, are you planning to configure any type of configuration in
>>>>>       order
>>>>>       to
>>>>>       setup the privacy of certain claims ?
>>>>
>>>> Forget about it. Just noticed you already have support for that.
>>>>
>>>
>>> Nothing beyond a few claims though.  Can't enter in address, phone, etc...
>>
>> I've submitted a PR for this issue. There are some changes to IDToken type
>> that would like to share and discuss.
>>
>> Today, user claims are strongly tied with the IDToken type. They are there as
>> properties of the type itself. From a token perspective, that is how they
>> are represented but from an internal perspective I think we can improve it a
>> little bit by introducing a specific type for user claims.
>>
>> IMO, a best design is to extract those specific claims from IDToken type and
>> get them into a specific UserClaimSet, which also helps to avoid code
>> duplication when claims are needed in different places. Just like we need it
>> in UserInfo.
>>
>> That allow us to better represent/manage user claims internally and keep
>> things more in sync with the specs, without break anything from a token
>> representation or functionality perspective.
>
> I'm not convinced about this. Other than IDToken and UserInfo endpoint I can't see any uses for this.
>
> Also, I reckon this will change a fair bit by introducing custom user profiles. Internally I reckon we'll be using user profiles, not claim-set.
>

My plan was the following:

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

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

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


UserProfileValue:
* id
* UserClaimType
* String value


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

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

* id
* UserProfileType
* String claimNameMapping

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

Bill


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

From psilva at redhat.com  Fri Jan 16 09:41:45 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 16 Jan 2015 09:41:45 -0500 (EST)
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <54B92142.7010407@redhat.com>
References: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
	<585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>
	<54B80FEA.8060704@redhat.com>
	<106136572.10561573.1421415005955.JavaMail.zimbra@redhat.com>
	<1597917021.11473783.1421417230594.JavaMail.zimbra@redhat.com>
	<54B92142.7010407@redhat.com>
Message-ID: <1614202933.10600412.1421419305382.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, January 16, 2015 12:33:38 PM
> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> 
> 
> 
> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 16 January, 2015 2:30:05 PM
> >> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, January 15, 2015 5:07:22 PM
> >>> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> >>>
> >>>
> >>>
> >>> On 1/15/2015 12:40 PM, Pedro Igor Silva wrote:
> >>>> ----- Original Message -----
> >>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>> Sent: Thursday, January 15, 2015 2:46:11 PM
> >>>>> Subject: KEYCLOAK-884 - UserInfo Endpoint
> >>>>>
> >>>>> Bill,
> >>>>>
> >>>>>       Is the work you are doing for claims considering the respective
> >>>>>       sections
> >>>>>       in OpenID Connect specification ? To be more specific,
> >>>>>       http://openid.net/specs/openid-connect-core-1_0.html#Claims.
> >>>>>
> >>>>>       Depending on what you are doing, I think I would need to wait you
> >>>>>       finish
> >>>>>       in order to full support what is expected from the UserInfo
> >>>>>       endpoint.
> >>>>>       Meanwhile, I'm already doing everything that is necessary to get
> >>>>>       the
> >>>>>       endpoint up and running with a basic interoperability based on
> >>>>>       the
> >>>>>       default scope values used to request claims (profile, email,
> >>>>>       address,
> >>>>>       phone).
> >>>>>
> >>>>>       Btw, are you planning to configure any type of configuration in
> >>>>>       order
> >>>>>       to
> >>>>>       setup the privacy of certain claims ?
> >>>>
> >>>> Forget about it. Just noticed you already have support for that.
> >>>>
> >>>
> >>> Nothing beyond a few claims though.  Can't enter in address, phone,
> >>> etc...
> >>
> >> I've submitted a PR for this issue. There are some changes to IDToken type
> >> that would like to share and discuss.
> >>
> >> Today, user claims are strongly tied with the IDToken type. They are there
> >> as
> >> properties of the type itself. From a token perspective, that is how they
> >> are represented but from an internal perspective I think we can improve it
> >> a
> >> little bit by introducing a specific type for user claims.
> >>
> >> IMO, a best design is to extract those specific claims from IDToken type
> >> and
> >> get them into a specific UserClaimSet, which also helps to avoid code
> >> duplication when claims are needed in different places. Just like we need
> >> it
> >> in UserInfo.
> >>
> >> That allow us to better represent/manage user claims internally and keep
> >> things more in sync with the specs, without break anything from a token
> >> representation or functionality perspective.
> >
> > I'm not convinced about this. Other than IDToken and UserInfo endpoint I
> > can't see any uses for this.
> >
> > Also, I reckon this will change a fair bit by introducing custom user
> > profiles. Internally I reckon we'll be using user profiles, not claim-set.
> >
> 
> My plan was the following:
> 
> Current UserModel.attributes will be used for internal bookkeeping only.
>   Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
> type that contains:
> 
> UserProfileType:
> * id
> * name
> * .css type
> * type (bool, int, date, etc.)
> * boolean displayOnRegistrationPage
> 
> Question, do I need a .css id to plug in a value too?  How would we
> display the german label name for "phone"?
> 
> 
> UserProfileValue:
> * id
> * UserClaimType
> * String value
> 
> 
> OIDC clients will have a "Claim mapping" tab.  SAML clients will have an
> "Assertion Mapping" tab.  

IMO, you can use Claims for both cases. Claims are also used to refer to SAML attributes and vice-verca. Claims are also a very know term in security area.

These tabs will be able to map from
> UserProfileValues to te appropriate claim/assertion and also be able to
> set up whether or not a claim should be added to token/assertion list.
> 
> ClientModel.claimMask will go away.  ClientModel will gain a list of
> ClaimMappingModel
> 
> * id
> * UserProfileType
> * String claimNameMapping
> 
> Might want to eventually add a "ClaimTransformerProvider" pluggin
> ability that can be attached to ClaimMappingModel...We might also want a
> "TokenTransformerProvider" plugin too that can intercept token/saml doc
> creation.  We'll see...
> 
> Bill
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri Jan 16 09:42:54 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Jan 2015 09:42:54 -0500
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <54B91E22.4060808@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B7BC24.5070501@redhat.com>	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>	<54B821D4.8040202@redhat.com>	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>	<54B90E74.9040704@redhat.com>	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com>
Message-ID: <54B9236E.7010904@redhat.com>



On 1/16/2015 9:20 AM, Stan Silvert wrote:
> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down to this issue. I should have raised it before, but it completely slipped my mind :(
> We did talk about this at great length before.   I tried and tried to
> preserve the "drop it in the file system" approach.  It just plain won't
> work for domains.
>>
>> IMO we need:
>>
>> 1. A usable way to deploy a provider without using the CLI GUI
>> 2. Ideally be able to deploy a provider with an offline server
> We have 5 ways to add a provider:
> 1. CLI
> 2. CLI GUI
> 3. CLI script
> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
> 5. Use the war dist and do it the old way.
>

6. Create a module for your new provider.  Import that module (with 
service import too) into the main Keycloak module.  Of course this 
requires knowledge of JBoss Modules.  Not sure if this would work.  You 
tell me.

BTW, come to think of it, this upload through CLI just won't work, if 
the provider has even one third-party library dependency.

Stan, can you explain again the issue with domain mode?  Is it that 
you're trying to secure the domain controller itself with keycloak?


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

From psilva at redhat.com  Fri Jan 16 09:48:02 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 16 Jan 2015 09:48:02 -0500 (EST)
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <1614202933.10600412.1421419305382.JavaMail.zimbra@redhat.com>
References: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
	<585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>
	<54B80FEA.8060704@redhat.com>
	<106136572.10561573.1421415005955.JavaMail.zimbra@redhat.com>
	<1597917021.11473783.1421417230594.JavaMail.zimbra@redhat.com>
	<54B92142.7010407@redhat.com>
	<1614202933.10600412.1421419305382.JavaMail.zimbra@redhat.com>
Message-ID: <1932342868.10605313.1421419682474.JavaMail.zimbra@redhat.com>

> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva"
> > <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, January 16, 2015 12:33:38 PM
> > Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> > 
> > Might want to eventually add a "ClaimTransformerProvider" pluggin
> > ability that can be attached to ClaimMappingModel...We might also want a
> > "TokenTransformerProvider" plugin too that can intercept token/saml doc
> > creation.  We'll see...
> > 

I think you will need that, for sure. We have something similar in PL SAML IdP and it helps a lot when you need more control on how claims are handled.

Regarding the "TokenTransformerProvider", that is also something you may need as well. We also provide something similar in PL SAML IdP, where users can customize the assertion before sending it back to SPs.

From mposolda at redhat.com  Fri Jan 16 09:50:05 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 16 Jan 2015 15:50:05 +0100
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <54B91E22.4060808@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B7BC24.5070501@redhat.com>	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>	<54B821D4.8040202@redhat.com>	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>	<54B90E74.9040704@redhat.com>	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com>
Message-ID: <54B9251D.8080204@redhat.com>

On 16.1.2015 15:20, Stan Silvert wrote:
> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down to this issue. I should have raised it before, but it completely slipped my mind :(
> We did talk about this at great length before.   I tried and tried to
> preserve the "drop it in the file system" approach.  It just plain won't
> work for domains.
>> IMO we need:
>>
>> 1. A usable way to deploy a provider without using the CLI GUI
>> 2. Ideally be able to deploy a provider with an offline server
> We have 5 ways to add a provider:
> 1. CLI
> 2. CLI GUI
> 3. CLI script
> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
I've just tried the exploded WAR approach, but had some issues. What I 
did with keycloak appliance was:
- Change the WAR file in 
modules/system/layers/base/org/keycloak/keycloak-subsystem/main/auth-server/keycloak-server-1.1.0.Final-SNAPSHOT.war 
to be exploded
- Change the configuration property "auth-server-exploded" to true in 
modules/system/layers/base/org/keycloak/keycloak-subsystem/main/module.xml

With this auth-server didn't bootstrap for me at startup. Once I added 
provider to exploded WAR and pack it back to be file instead of 
directory, it started to work and my provider is found.

So in shortcut, adding provider in offline mode works, but I needed to: 
unpack, copy provider JAR, pack it back.

Did I something wrong to have exploded WAR working? Also can subsystem 
work with having exploded WAR by default? In this case it will be easy 
to add provider in offline mode as people can just copy them to unpacked 
location inside keycloak subsystem .

Sorry if you already discuss this possibility, I may miss some details 
in previous discussion related to this;-)

Marek

> 5. Use the war dist and do it the old way.
>
> Why are these not sufficient?
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-user at lists.jboss.org
>>> Sent: Friday, 16 January, 2015 2:13:24 PM
>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
>>>
>>> On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-user at lists.jboss.org
>>>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>>> Keycloak 1.1 Beta-2
>>>>>
>>>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>>>>> How is a provider added using the CLI? I can't find any examples on that.
>>>>> In the doc there is a step-by-step example of how to do it.  See section
>>>>> 3.4.2.2.
>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>> That example uses the CLI GUI, we need one that uses plain CLI
>>> Plain CLI is harder in this case.  CLI GUI lets you browse for the file
>>> you need.   Overall, plain CLI is a lot more error prone.
>>>
>>> If you do this once in CLI GUI then you will generate the CLI command
>>> that you can cut and paste into plain CLI or a script.  But if you want,
>>> I can include an example of that command.
>>>> There's also another issue with this approach, which I didn't stress enough
>>>> last time around, it requires the server to be running to add providers.
>>>> That makes it much harder to for example create a Docker cartridge that
>>>> includes some custom providers.
>>> Perhaps we just need to document the fact that you can still explode the
>>> WAR and do it the old way?
>>>>>> Also, there are still several references in the docs and examples that
>>>>>> uses
>>>>>> the old approach of copying to WEB-INF/lib.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>> To: keycloak-user at lists.jboss.org
>>>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>>>>> Keycloak 1.1 Beta-2
>>>>>>>
>>>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>>>>
>>>>>>> See
>>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>>>>
>>>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I created a custom User Federation Provider and deployed it as per the
>>>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it appears
>>>>>>> that the location of Keycloak war in Wildfly has changed in 1.1 Beta-2
>>>>>>> version and it is no longer inflated. Can someone suggest where exactly
>>>>>>> I
>>>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Raghu
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Jan 16 10:17:18 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 Jan 2015 10:17:18 -0500 (EST)
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <54B91E22.4060808@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>
	<54B7BC24.5070501@redhat.com>
	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>
	<54B821D4.8040202@redhat.com>
	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
	<54B90E74.9040704@redhat.com>
	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com>
Message-ID: <651223121.11549801.1421421438944.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 January, 2015 3:20:18 PM
> Subject: Re: [keycloak-user] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
> 
> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
> > Currently, I'm not overly happy with releasing 1.1.0.Final and it's down to
> > this issue. I should have raised it before, but it completely slipped my
> > mind :(
> We did talk about this at great length before.   I tried and tried to
> preserve the "drop it in the file system" approach.  It just plain won't
> work for domains.

I know we did, but I like changing my mind ;)

> >
> > IMO we need:
> >
> > 1. A usable way to deploy a provider without using the CLI GUI
> > 2. Ideally be able to deploy a provider with an offline server
> We have 5 ways to add a provider:
> 1. CLI
> 2. CLI GUI
> 3. CLI script
> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
> 5. Use the war dist and do it the old way.

1-3. If the CLI was easy to use that would work, except we also need to be able to do it offline. I don't really like the deployment overalys as it all feels a bit magical and black boxed.
4.   I hate this - the user shouldn't have to explode the WAR and also it's in a really strange place for a user to find
5.   That's not an option for the appliance

Maybe what we could do for now is to create add-provider.sh/bat scripts that makes it easier to do without any knowledge of CLI.

Can we not use modules as Bill suggests? We could make the keycloak subsystem depend on a keycloak-providers module and users would register their provider modules there.

> 
> Why are these not sufficient?
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-user at lists.jboss.org
> >> Sent: Friday, 16 January, 2015 2:13:24 PM
> >> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
> >> Keycloak 1.1 Beta-2
> >>
> >> On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
> >>> ----- Original Message -----
> >>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-user at lists.jboss.org
> >>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
> >>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
> >>>> Keycloak 1.1 Beta-2
> >>>>
> >>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
> >>>>> How is a provider added using the CLI? I can't find any examples on
> >>>>> that.
> >>>> In the doc there is a step-by-step example of how to do it.  See section
> >>>> 3.4.2.2.
> >>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
> >>> That example uses the CLI GUI, we need one that uses plain CLI
> >> Plain CLI is harder in this case.  CLI GUI lets you browse for the file
> >> you need.   Overall, plain CLI is a lot more error prone.
> >>
> >> If you do this once in CLI GUI then you will generate the CLI command
> >> that you can cut and paste into plain CLI or a script.  But if you want,
> >> I can include an example of that command.
> >>> There's also another issue with this approach, which I didn't stress
> >>> enough
> >>> last time around, it requires the server to be running to add providers.
> >>> That makes it much harder to for example create a Docker cartridge that
> >>> includes some custom providers.
> >> Perhaps we just need to document the fact that you can still explode the
> >> WAR and do it the old way?
> >>>>> Also, there are still several references in the docs and examples that
> >>>>> uses
> >>>>> the old approach of copying to WEB-INF/lib.
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>>>> To: keycloak-user at lists.jboss.org
> >>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
> >>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar
> >>>>>> in
> >>>>>> Keycloak 1.1 Beta-2
> >>>>>>
> >>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
> >>>>>>
> >>>>>> See
> >>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
> >>>>>>
> >>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I created a custom User Federation Provider and deployed it as per the
> >>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it
> >>>>>> appears
> >>>>>> that the location of Keycloak war in Wildfly has changed in 1.1 Beta-2
> >>>>>> version and it is no longer inflated. Can someone suggest where
> >>>>>> exactly
> >>>>>> I
> >>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Raghu
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> keycloak-user mailing list keycloak-user at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> keycloak-user mailing list
> >>>>>> keycloak-user at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> 
> 

From stian at redhat.com  Fri Jan 16 10:24:44 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 Jan 2015 10:24:44 -0500 (EST)
Subject: [keycloak-dev] Where's 1.1.0.Final?
In-Reply-To: <1803860191.11551495.1421421587274.JavaMail.zimbra@redhat.com>
Message-ID: <1609140300.11555839.1421421884856.JavaMail.zimbra@redhat.com>

Due to a far amount of bugs and issues with Jenkins there's no release this week. We're getting close though and we will release next week!

From ssilvert at redhat.com  Fri Jan 16 10:28:37 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 Jan 2015 10:28:37 -0500
Subject: [keycloak-dev] Location of User Federation Provider jar in
 Keycloak 1.1 Beta-2
In-Reply-To: <54B9236E.7010904@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B7BC24.5070501@redhat.com>	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>	<54B821D4.8040202@redhat.com>	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>	<54B90E74.9040704@redhat.com>	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com> <54B9236E.7010904@redhat.com>
Message-ID: <54B92E25.9080304@redhat.com>

On 1/16/2015 9:42 AM, Bill Burke wrote:
>
> On 1/16/2015 9:20 AM, Stan Silvert wrote:
>> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down to this issue. I should have raised it before, but it completely slipped my mind :(
>> We did talk about this at great length before.   I tried and tried to
>> preserve the "drop it in the file system" approach.  It just plain won't
>> work for domains.
>>> IMO we need:
>>>
>>> 1. A usable way to deploy a provider without using the CLI GUI
>>> 2. Ideally be able to deploy a provider with an offline server
>> We have 5 ways to add a provider:
>> 1. CLI
>> 2. CLI GUI
>> 3. CLI script
>> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
>> 5. Use the war dist and do it the old way.
>>
> 6. Create a module for your new provider.  Import that module (with
> service import too) into the main Keycloak module.  Of course this
> requires knowledge of JBoss Modules.  Not sure if this would work.  You
> tell me.
I tried that and ran into problems.  I consulted with Jason and Stuart 
to see if there was any way to get it to work.  They concluded that it 
probably could be made to work but it would require moving everything 
out of the WEB-INF/lib and creating modules for each jar.  I don't 
remember all the details but I can probably find the chat log where we 
discussed it.

At the time I didn't want to go that far because pulling everything out 
of the WAR and forcing the user to create modules seemed like too 
radical of a change.  But maybe we need to revisit that.  We've already 
been talking about moving more stuff into modules.  If we decide to not 
support the auth server on other platforms then it would make even more 
sense to go ahead and do it because we wouldn't be tied to testing 
everything as a WAR.
>
> BTW, come to think of it, this upload through CLI just won't work, if
> the provider has even one third-party library dependency.
It still works.  You can upload as many provider jars as you want.
>
> Stan, can you explain again the issue with domain mode?  Is it that
> you're trying to secure the domain controller itself with keycloak?
>
>
The domain controller won't be secured with Keycloak until we integrate 
with Elytron.   But having Keycloak compatible with domain mode is a 
piece of that puzzle.

Deployment scanners are not allowed in domain mode.  You upload to the 
domain controller and the deployment is distributed to wherever you want 
it to run.   So there is no place in the file system where you can just 
copy a file and have it become part of the deployment.    And as I found 
out, there is no way to create your own deployment scanner that will 
work.  The architecture blocks you from doing that.

Operationally, using overlays is a lot cleaner for upgrades, especially 
in domain mode.   Your provider jar is the thing most likely to change.  
So when it does, you just need to upload the one jar and you are done.  
Same is true for keycloak-server.json changes.

If you used a single hacked-up WAR, you would need to rebuild the entire 
WAR off line and upload the whole thing.  So you would also need to keep 
up with manually versioning your own customized WAR.

From stian at redhat.com  Fri Jan 16 10:32:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 16 Jan 2015 10:32:31 -0500 (EST)
Subject: [keycloak-dev] Location of User Federation Provider jar in
 Keycloak 1.1 Beta-2
In-Reply-To: <54B92E25.9080304@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>
	<54B821D4.8040202@redhat.com>
	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
	<54B90E74.9040704@redhat.com>
	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com> <54B9236E.7010904@redhat.com>
	<54B92E25.9080304@redhat.com>
Message-ID: <1439341042.11564142.1421422351957.JavaMail.zimbra@redhat.com>

Sent out an invite for a meeting on Monday (4pm CET), is everyone available to join?

I'd like to discuss this issue in person before doing the release.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 January, 2015 4:28:37 PM
> Subject: Re: [keycloak-dev] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
> 
> On 1/16/2015 9:42 AM, Bill Burke wrote:
> >
> > On 1/16/2015 9:20 AM, Stan Silvert wrote:
> >> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
> >>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down
> >>> to this issue. I should have raised it before, but it completely slipped
> >>> my mind :(
> >> We did talk about this at great length before.   I tried and tried to
> >> preserve the "drop it in the file system" approach.  It just plain won't
> >> work for domains.
> >>> IMO we need:
> >>>
> >>> 1. A usable way to deploy a provider without using the CLI GUI
> >>> 2. Ideally be able to deploy a provider with an offline server
> >> We have 5 ways to add a provider:
> >> 1. CLI
> >> 2. CLI GUI
> >> 3. CLI script
> >> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
> >> 5. Use the war dist and do it the old way.
> >>
> > 6. Create a module for your new provider.  Import that module (with
> > service import too) into the main Keycloak module.  Of course this
> > requires knowledge of JBoss Modules.  Not sure if this would work.  You
> > tell me.
> I tried that and ran into problems.  I consulted with Jason and Stuart
> to see if there was any way to get it to work.  They concluded that it
> probably could be made to work but it would require moving everything
> out of the WEB-INF/lib and creating modules for each jar.  I don't
> remember all the details but I can probably find the chat log where we
> discussed it.
> 
> At the time I didn't want to go that far because pulling everything out
> of the WAR and forcing the user to create modules seemed like too
> radical of a change.  But maybe we need to revisit that.  We've already
> been talking about moving more stuff into modules.  If we decide to not
> support the auth server on other platforms then it would make even more
> sense to go ahead and do it because we wouldn't be tied to testing
> everything as a WAR.
> >
> > BTW, come to think of it, this upload through CLI just won't work, if
> > the provider has even one third-party library dependency.
> It still works.  You can upload as many provider jars as you want.
> >
> > Stan, can you explain again the issue with domain mode?  Is it that
> > you're trying to secure the domain controller itself with keycloak?
> >
> >
> The domain controller won't be secured with Keycloak until we integrate
> with Elytron.   But having Keycloak compatible with domain mode is a
> piece of that puzzle.
> 
> Deployment scanners are not allowed in domain mode.  You upload to the
> domain controller and the deployment is distributed to wherever you want
> it to run.   So there is no place in the file system where you can just
> copy a file and have it become part of the deployment.    And as I found
> out, there is no way to create your own deployment scanner that will
> work.  The architecture blocks you from doing that.
> 
> Operationally, using overlays is a lot cleaner for upgrades, especially
> in domain mode.   Your provider jar is the thing most likely to change.
> So when it does, you just need to upload the one jar and you are done.
> Same is true for keycloak-server.json changes.
> 
> If you used a single hacked-up WAR, you would need to rebuild the entire
> WAR off line and upload the whole thing.  So you would also need to keep
> up with manually versioning your own customized WAR.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Fri Jan 16 10:35:59 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 Jan 2015 10:35:59 -0500
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <54B9251D.8080204@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B7BC24.5070501@redhat.com>	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>	<54B821D4.8040202@redhat.com>	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>	<54B90E74.9040704@redhat.com>	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com> <54B9251D.8080204@redhat.com>
Message-ID: <54B92FDF.6060704@redhat.com>

I tested exploded mode yesterday with the latest release and it worked 
fine for me.  Maybe you exploded it at the wrong directory level?

On 1/16/2015 9:50 AM, Marek Posolda wrote:
> On 16.1.2015 15:20, Stan Silvert wrote:
>> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's 
>>> down to this issue. I should have raised it before, but it 
>>> completely slipped my mind :(
>> We did talk about this at great length before.   I tried and tried to
>> preserve the "drop it in the file system" approach.  It just plain won't
>> work for domains.
>>> IMO we need:
>>>
>>> 1. A usable way to deploy a provider without using the CLI GUI
>>> 2. Ideally be able to deploy a provider with an offline server
>> We have 5 ways to add a provider:
>> 1. CLI
>> 2. CLI GUI
>> 3. CLI script
>> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
> I've just tried the exploded WAR approach, but had some issues. What I 
> did with keycloak appliance was:
> - Change the WAR file in 
> modules/system/layers/base/org/keycloak/keycloak-subsystem/main/auth-server/keycloak-server-1.1.0.Final-SNAPSHOT.war 
> to be exploded
> - Change the configuration property "auth-server-exploded" to true in 
> modules/system/layers/base/org/keycloak/keycloak-subsystem/main/module.xml
>
> With this auth-server didn't bootstrap for me at startup. Once I added 
> provider to exploded WAR and pack it back to be file instead of 
> directory, it started to work and my provider is found.
>
> So in shortcut, adding provider in offline mode works, but I needed 
> to: unpack, copy provider JAR, pack it back.
>
> Did I something wrong to have exploded WAR working? Also can subsystem 
> work with having exploded WAR by default? In this case it will be easy 
> to add provider in offline mode as people can just copy them to 
> unpacked location inside keycloak subsystem .
>
> Sorry if you already discuss this possibility, I may miss some details 
> in previous discussion related to this;-)
>
> Marek
>
>> 5. Use the war dist and do it the old way.
>>
>> Why are these not sufficient?
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-user at lists.jboss.org
>>>> Sent: Friday, 16 January, 2015 2:13:24 PM
>>>> Subject: Re: [keycloak-user] Location of User Federation Provider 
>>>> jar in Keycloak 1.1 Beta-2
>>>>
>>>> On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: keycloak-user at lists.jboss.org
>>>>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider 
>>>>>> jar in
>>>>>> Keycloak 1.1 Beta-2
>>>>>>
>>>>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>>>>>> How is a provider added using the CLI? I can't find any examples 
>>>>>>> on that.
>>>>>> In the doc there is a step-by-step example of how to do it.  See 
>>>>>> section
>>>>>> 3.4.2.2.
>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350 
>>>>>>
>>>>> That example uses the CLI GUI, we need one that uses plain CLI
>>>> Plain CLI is harder in this case.  CLI GUI lets you browse for the 
>>>> file
>>>> you need.   Overall, plain CLI is a lot more error prone.
>>>>
>>>> If you do this once in CLI GUI then you will generate the CLI command
>>>> that you can cut and paste into plain CLI or a script.  But if you 
>>>> want,
>>>> I can include an example of that command.
>>>>> There's also another issue with this approach, which I didn't 
>>>>> stress enough
>>>>> last time around, it requires the server to be running to add 
>>>>> providers.
>>>>> That makes it much harder to for example create a Docker cartridge 
>>>>> that
>>>>> includes some custom providers.
>>>> Perhaps we just need to document the fact that you can still 
>>>> explode the
>>>> WAR and do it the old way?
>>>>>>> Also, there are still several references in the docs and 
>>>>>>> examples that
>>>>>>> uses
>>>>>>> the old approach of copying to WEB-INF/lib.
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>>> To: keycloak-user at lists.jboss.org
>>>>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>>>>>> Subject: Re: [keycloak-user] Location of User Federation 
>>>>>>>> Provider jar in
>>>>>>>> Keycloak 1.1 Beta-2
>>>>>>>>
>>>>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>>>>>
>>>>>>>> See
>>>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350 
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I created a custom User Federation Provider and deployed it as 
>>>>>>>> per the
>>>>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but 
>>>>>>>> it appears
>>>>>>>> that the location of Keycloak war in Wildfly has changed in 1.1 
>>>>>>>> Beta-2
>>>>>>>> version and it is no longer inflated. Can someone suggest where 
>>>>>>>> exactly
>>>>>>>> I
>>>>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Raghu
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From bburke at redhat.com  Fri Jan 16 10:44:05 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Jan 2015 10:44:05 -0500
Subject: [keycloak-dev] Location of User Federation Provider jar in
 Keycloak 1.1 Beta-2
In-Reply-To: <1439341042.11564142.1421422351957.JavaMail.zimbra@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B821D4.8040202@redhat.com>	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>	<54B90E74.9040704@redhat.com>	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>	<54B91E22.4060808@redhat.com>
	<54B9236E.7010904@redhat.com>	<54B92E25.9080304@redhat.com>
	<1439341042.11564142.1421422351957.JavaMail.zimbra@redhat.com>
Message-ID: <54B931C5.7050402@redhat.com>

I am off on Monday.  Damn kids have a holiday and I'll be driving them 
around to their activities from 7:00am-7pm.

On 1/16/2015 10:32 AM, Stian Thorgersen wrote:
> Sent out an invite for a meeting on Monday (4pm CET), is everyone available to join?
>
> I'd like to discuss this issue in person before doing the release.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 16 January, 2015 4:28:37 PM
>> Subject: Re: [keycloak-dev] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
>>
>> On 1/16/2015 9:42 AM, Bill Burke wrote:
>>>
>>> On 1/16/2015 9:20 AM, Stan Silvert wrote:
>>>> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>>>>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down
>>>>> to this issue. I should have raised it before, but it completely slipped
>>>>> my mind :(
>>>> We did talk about this at great length before.   I tried and tried to
>>>> preserve the "drop it in the file system" approach.  It just plain won't
>>>> work for domains.
>>>>> IMO we need:
>>>>>
>>>>> 1. A usable way to deploy a provider without using the CLI GUI
>>>>> 2. Ideally be able to deploy a provider with an offline server
>>>> We have 5 ways to add a provider:
>>>> 1. CLI
>>>> 2. CLI GUI
>>>> 3. CLI script
>>>> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
>>>> 5. Use the war dist and do it the old way.
>>>>
>>> 6. Create a module for your new provider.  Import that module (with
>>> service import too) into the main Keycloak module.  Of course this
>>> requires knowledge of JBoss Modules.  Not sure if this would work.  You
>>> tell me.
>> I tried that and ran into problems.  I consulted with Jason and Stuart
>> to see if there was any way to get it to work.  They concluded that it
>> probably could be made to work but it would require moving everything
>> out of the WEB-INF/lib and creating modules for each jar.  I don't
>> remember all the details but I can probably find the chat log where we
>> discussed it.
>>
>> At the time I didn't want to go that far because pulling everything out
>> of the WAR and forcing the user to create modules seemed like too
>> radical of a change.  But maybe we need to revisit that.  We've already
>> been talking about moving more stuff into modules.  If we decide to not
>> support the auth server on other platforms then it would make even more
>> sense to go ahead and do it because we wouldn't be tied to testing
>> everything as a WAR.
>>>
>>> BTW, come to think of it, this upload through CLI just won't work, if
>>> the provider has even one third-party library dependency.
>> It still works.  You can upload as many provider jars as you want.
>>>
>>> Stan, can you explain again the issue with domain mode?  Is it that
>>> you're trying to secure the domain controller itself with keycloak?
>>>
>>>
>> The domain controller won't be secured with Keycloak until we integrate
>> with Elytron.   But having Keycloak compatible with domain mode is a
>> piece of that puzzle.
>>
>> Deployment scanners are not allowed in domain mode.  You upload to the
>> domain controller and the deployment is distributed to wherever you want
>> it to run.   So there is no place in the file system where you can just
>> copy a file and have it become part of the deployment.    And as I found
>> out, there is no way to create your own deployment scanner that will
>> work.  The architecture blocks you from doing that.
>>
>> Operationally, using overlays is a lot cleaner for upgrades, especially
>> in domain mode.   Your provider jar is the thing most likely to change.
>> So when it does, you just need to upload the one jar and you are done.
>> Same is true for keycloak-server.json changes.
>>
>> If you used a single hacked-up WAR, you would need to rebuild the entire
>> WAR off line and upload the whole thing.  So you would also need to keep
>> up with manually versioning your own customized WAR.
>> _______________________________________________
>> 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 juraci at kroehling.de  Fri Jan 16 11:31:25 2015
From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Fri, 16 Jan 2015 17:31:25 +0100
Subject: [keycloak-dev] WebSocket integration
Message-ID: <54B93CDD.8060108@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

I'm investigating the possibility of protecting a WebSocket endpoint
with Keycloak and I found out that it works out of the box with
cookie-based authentication, meaning, the web page that opens the web
socket client should itself be protected, so that the cookie is sent
on the WebSocket request and authentication is made (confidential).

In my target scenario, however, the web page is a single-page app
(public) talking with a backend (bearer-only) in another host.

So, I'd like to know if there's anything planned on the WebSockets
front for such scenario. For instance, a JavaScript utility that
handles the setup of the socket (either with a custom protocol, or an
initial message with the bearer token, or another alternative) and a
server counterpart for this.

If there isn't yet, I'll probably have some time to explore this.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUuTzdAAoJEDnJtskdmzLMgSIH/2eGoZSzUcsXL2zs7tyLEAIL
LTHBOY0vlr3KDRIWMcab8ijIAKt5u+JQnb4fJlEEXW1C8+QKNSDJYsfj/HcGnDcg
TM2kzhy4HS9O8CnlRqKEm6FlRKfgV3R/64huFXCRXmIdkxiKGgMQvmhWmlrDFHVy
ZRtaNk3e433LkD4/fYdWIobjdtxZTv4xAglWAgXCAVdXJCy8Sp+yiopU7LNMqb75
mgWk89h8U5nl/J9HuAd8+oZH9qg35lwI1LZOPRRwpyl4td4x1tDR2lQc1SJmS47g
N2ES3jTtGHWMDEfsxDyLIQ6TmC1+r1Yoid51jILqaxlYGWgH/eRtnwny0Qczj+w=
=x0ZO
-----END PGP SIGNATURE-----

From ssilvert at redhat.com  Fri Jan 16 11:41:59 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 16 Jan 2015 11:41:59 -0500
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <651223121.11549801.1421421438944.JavaMail.zimbra@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>
	<54B7BC24.5070501@redhat.com>
	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>
	<54B821D4.8040202@redhat.com>
	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
	<54B90E74.9040704@redhat.com>
	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com>
	<651223121.11549801.1421421438944.JavaMail.zimbra@redhat.com>
Message-ID: <54B93F57.9070303@redhat.com>

On 1/16/2015 10:17 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 16 January, 2015 3:20:18 PM
>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
>>
>> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down to
>>> this issue. I should have raised it before, but it completely slipped my
>>> mind :(
>> We did talk about this at great length before.   I tried and tried to
>> preserve the "drop it in the file system" approach.  It just plain won't
>> work for domains.
> I know we did, but I like changing my mind ;)
>
>>> IMO we need:
>>>
>>> 1. A usable way to deploy a provider without using the CLI GUI
>>> 2. Ideally be able to deploy a provider with an offline server
>> We have 5 ways to add a provider:
>> 1. CLI
>> 2. CLI GUI
>> 3. CLI script
>> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
>> 5. Use the war dist and do it the old way.
> 1-3. If the CLI was easy to use that would work, except we also need to be able to do it offline.
We can ship a script that makes this task a little easier as you suggest 
below.

As for offline, I don't understand what the problem is.  You mentioned 
docker, which I haven't looked at much.  Why can't you have an image 
that was created from an overlaid Keycloak server?
>   I don't really like the deployment overalys as it all feels a bit magical and black boxed.
Don't you think it's better than telling them to hack our WAR?
> 4.   I hate this - the user shouldn't have to explode the WAR and also it's in a really strange place for a user to find
I hate it too.  I almost wish I hadn't implemented exploded mode.  I 
re-verified that it is working, btw.
> 5.   That's not an option for the appliance
You still could do it with the appliance if you wanted.

But the idea of the appliance is that you shouldn't need to change it 
except through a UI.  That's where the overlay method will really shine, 
especially when we can get provider management into our own UI.  At that 
point, copying jars to a file system will look extremely primitive in 
comparison.
>
> Maybe what we could do for now is to create add-provider.sh/bat scripts that makes it easier to do without any knowledge of CLI.
>
> Can we not use modules as Bill suggests? We could make the keycloak subsystem depend on a keycloak-providers module and users would register their provider modules there.
>
>> Why are these not sufficient?
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-user at lists.jboss.org
>>>> Sent: Friday, 16 January, 2015 2:13:24 PM
>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>> Keycloak 1.1 Beta-2
>>>>
>>>> On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: keycloak-user at lists.jboss.org
>>>>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>>>> Keycloak 1.1 Beta-2
>>>>>>
>>>>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>>>>>> How is a provider added using the CLI? I can't find any examples on
>>>>>>> that.
>>>>>> In the doc there is a step-by-step example of how to do it.  See section
>>>>>> 3.4.2.2.
>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>> That example uses the CLI GUI, we need one that uses plain CLI
>>>> Plain CLI is harder in this case.  CLI GUI lets you browse for the file
>>>> you need.   Overall, plain CLI is a lot more error prone.
>>>>
>>>> If you do this once in CLI GUI then you will generate the CLI command
>>>> that you can cut and paste into plain CLI or a script.  But if you want,
>>>> I can include an example of that command.
>>>>> There's also another issue with this approach, which I didn't stress
>>>>> enough
>>>>> last time around, it requires the server to be running to add providers.
>>>>> That makes it much harder to for example create a Docker cartridge that
>>>>> includes some custom providers.
>>>> Perhaps we just need to document the fact that you can still explode the
>>>> WAR and do it the old way?
>>>>>>> Also, there are still several references in the docs and examples that
>>>>>>> uses
>>>>>>> the old approach of copying to WEB-INF/lib.
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>>> To: keycloak-user at lists.jboss.org
>>>>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar
>>>>>>>> in
>>>>>>>> Keycloak 1.1 Beta-2
>>>>>>>>
>>>>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>>>>>
>>>>>>>> See
>>>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>>>>>
>>>>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I created a custom User Federation Provider and deployed it as per the
>>>>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it
>>>>>>>> appears
>>>>>>>> that the location of Keycloak war in Wildfly has changed in 1.1 Beta-2
>>>>>>>> version and it is no longer inflated. Can someone suggest where
>>>>>>>> exactly
>>>>>>>> I
>>>>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Raghu
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>


From bburke at redhat.com  Fri Jan 16 11:42:13 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Jan 2015 11:42:13 -0500
Subject: [keycloak-dev] WebSocket integration
In-Reply-To: <54B93CDD.8060108@kroehling.de>
References: <54B93CDD.8060108@kroehling.de>
Message-ID: <54B93F65.4080202@redhat.com>

Single page app would work with cookie and server side adapter.  I don't 
know how it would work with javascript.  You'd have to send the token 
with the HTTP Upgrade request.

On 1/16/2015 11:31 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> I'm investigating the possibility of protecting a WebSocket endpoint
> with Keycloak and I found out that it works out of the box with
> cookie-based authentication, meaning, the web page that opens the web
> socket client should itself be protected, so that the cookie is sent
> on the WebSocket request and authentication is made (confidential).
>
> In my target scenario, however, the web page is a single-page app
> (public) talking with a backend (bearer-only) in another host.
>
> So, I'd like to know if there's anything planned on the WebSockets
> front for such scenario. For instance, a JavaScript utility that
> handles the setup of the socket (either with a custom protocol, or an
> initial message with the bearer token, or another alternative) and a
> server counterpart for this.
>
> If there isn't yet, I'll probably have some time to explore this.
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUuTzdAAoJEDnJtskdmzLMgSIH/2eGoZSzUcsXL2zs7tyLEAIL
> LTHBOY0vlr3KDRIWMcab8ijIAKt5u+JQnb4fJlEEXW1C8+QKNSDJYsfj/HcGnDcg
> TM2kzhy4HS9O8CnlRqKEm6FlRKfgV3R/64huFXCRXmIdkxiKGgMQvmhWmlrDFHVy
> ZRtaNk3e433LkD4/fYdWIobjdtxZTv4xAglWAgXCAVdXJCy8Sp+yiopU7LNMqb75
> mgWk89h8U5nl/J9HuAd8+oZH9qg35lwI1LZOPRRwpyl4td4x1tDR2lQc1SJmS47g
> N2ES3jTtGHWMDEfsxDyLIQ6TmC1+r1Yoid51jILqaxlYGWgH/eRtnwny0Qczj+w=
> =x0ZO
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From mposolda at redhat.com  Fri Jan 16 12:19:02 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 16 Jan 2015 18:19:02 +0100
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <54B92FDF.6060704@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B7BC24.5070501@redhat.com>	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>	<54B821D4.8040202@redhat.com>	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>	<54B90E74.9040704@redhat.com>	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com> <54B9251D.8080204@redhat.com>
	<54B92FDF.6060704@redhat.com>
Message-ID: <54B94806.8050502@redhat.com>

Ok, I figured that I need to unzip WAR directly into auth-server 
directory to have structure like 
modules/system/layers/base/org/keycloak/keycloak-subsystem/main/auth-server/WEB-INF/... 
.

What I did before was converting WAR file to directory of the same name, 
so I had structure like: 
modules/system/layers/base/org/keycloak/keycloak-subsystem/main/auth-server/keycloak-server-1.1.0.Final-SNAPSHOT.war/WEB-INF/... 


Thanks!
Marek

On 16.1.2015 16:35, Stan Silvert wrote:
> I tested exploded mode yesterday with the latest release and it worked 
> fine for me.  Maybe you exploded it at the wrong directory level?
>
> On 1/16/2015 9:50 AM, Marek Posolda wrote:
>> On 16.1.2015 15:20, Stan Silvert wrote:
>>> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>>>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's 
>>>> down to this issue. I should have raised it before, but it 
>>>> completely slipped my mind :(
>>> We did talk about this at great length before.   I tried and tried to
>>> preserve the "drop it in the file system" approach.  It just plain 
>>> won't
>>> work for domains.
>>>> IMO we need:
>>>>
>>>> 1. A usable way to deploy a provider without using the CLI GUI
>>>> 2. Ideally be able to deploy a provider with an offline server
>>> We have 5 ways to add a provider:
>>> 1. CLI
>>> 2. CLI GUI
>>> 3. CLI script
>>> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
>> I've just tried the exploded WAR approach, but had some issues. What 
>> I did with keycloak appliance was:
>> - Change the WAR file in 
>> modules/system/layers/base/org/keycloak/keycloak-subsystem/main/auth-server/keycloak-server-1.1.0.Final-SNAPSHOT.war 
>> to be exploded
>> - Change the configuration property "auth-server-exploded" to true in 
>> modules/system/layers/base/org/keycloak/keycloak-subsystem/main/module.xml
>>
>> With this auth-server didn't bootstrap for me at startup. Once I 
>> added provider to exploded WAR and pack it back to be file instead of 
>> directory, it started to work and my provider is found.
>>
>> So in shortcut, adding provider in offline mode works, but I needed 
>> to: unpack, copy provider JAR, pack it back.
>>
>> Did I something wrong to have exploded WAR working? Also can 
>> subsystem work with having exploded WAR by default? In this case it 
>> will be easy to add provider in offline mode as people can just copy 
>> them to unpacked location inside keycloak subsystem .
>>
>> Sorry if you already discuss this possibility, I may miss some 
>> details in previous discussion related to this;-)
>>
>> Marek
>>
>>> 5. Use the war dist and do it the old way.
>>>
>>> Why are these not sufficient?
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-user at lists.jboss.org
>>>>> Sent: Friday, 16 January, 2015 2:13:24 PM
>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider 
>>>>> jar in Keycloak 1.1 Beta-2
>>>>>
>>>>> On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: keycloak-user at lists.jboss.org
>>>>>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>>>>>>> Subject: Re: [keycloak-user] Location of User Federation 
>>>>>>> Provider jar in
>>>>>>> Keycloak 1.1 Beta-2
>>>>>>>
>>>>>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>>>>>>> How is a provider added using the CLI? I can't find any 
>>>>>>>> examples on that.
>>>>>>> In the doc there is a step-by-step example of how to do it.  See 
>>>>>>> section
>>>>>>> 3.4.2.2.
>>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350 
>>>>>>>
>>>>>> That example uses the CLI GUI, we need one that uses plain CLI
>>>>> Plain CLI is harder in this case.  CLI GUI lets you browse for the 
>>>>> file
>>>>> you need.   Overall, plain CLI is a lot more error prone.
>>>>>
>>>>> If you do this once in CLI GUI then you will generate the CLI command
>>>>> that you can cut and paste into plain CLI or a script. But if you 
>>>>> want,
>>>>> I can include an example of that command.
>>>>>> There's also another issue with this approach, which I didn't 
>>>>>> stress enough
>>>>>> last time around, it requires the server to be running to add 
>>>>>> providers.
>>>>>> That makes it much harder to for example create a Docker 
>>>>>> cartridge that
>>>>>> includes some custom providers.
>>>>> Perhaps we just need to document the fact that you can still 
>>>>> explode the
>>>>> WAR and do it the old way?
>>>>>>>> Also, there are still several references in the docs and 
>>>>>>>> examples that
>>>>>>>> uses
>>>>>>>> the old approach of copying to WEB-INF/lib.
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>>>> To: keycloak-user at lists.jboss.org
>>>>>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>>>>>>> Subject: Re: [keycloak-user] Location of User Federation 
>>>>>>>>> Provider jar in
>>>>>>>>> Keycloak 1.1 Beta-2
>>>>>>>>>
>>>>>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>>>>>>
>>>>>>>>> See
>>>>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I created a custom User Federation Provider and deployed it as 
>>>>>>>>> per the
>>>>>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but 
>>>>>>>>> it appears
>>>>>>>>> that the location of Keycloak war in Wildfly has changed in 
>>>>>>>>> 1.1 Beta-2
>>>>>>>>> version and it is no longer inflated. Can someone suggest 
>>>>>>>>> where exactly
>>>>>>>>> I
>>>>>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Raghu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


From mposolda at redhat.com  Fri Jan 16 12:25:18 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 16 Jan 2015 18:25:18 +0100
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <54B93F57.9070303@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>	<54B7BC24.5070501@redhat.com>	<2044258792.10860475.1421332192062.JavaMail.zimbra@redhat.com>	<54B821D4.8040202@redhat.com>	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>	<54B90E74.9040704@redhat.com>	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>	<54B91E22.4060808@redhat.com>	<651223121.11549801.1421421438944.JavaMail.zimbra@redhat.com>
	<54B93F57.9070303@redhat.com>
Message-ID: <54B9497E.2060700@redhat.com>

On 16.1.2015 17:41, Stan Silvert wrote:
> On 1/16/2015 10:17 AM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 16 January, 2015 3:20:18 PM
>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
>>>
>>> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
>>>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down to
>>>> this issue. I should have raised it before, but it completely slipped my
>>>> mind :(
>>> We did talk about this at great length before.   I tried and tried to
>>> preserve the "drop it in the file system" approach.  It just plain won't
>>> work for domains.
>> I know we did, but I like changing my mind ;)
>>
>>>> IMO we need:
>>>>
>>>> 1. A usable way to deploy a provider without using the CLI GUI
>>>> 2. Ideally be able to deploy a provider with an offline server
>>> We have 5 ways to add a provider:
>>> 1. CLI
>>> 2. CLI GUI
>>> 3. CLI script
>>> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
>>> 5. Use the war dist and do it the old way.
>> 1-3. If the CLI was easy to use that would work, except we also need to be able to do it offline.
> We can ship a script that makes this task a little easier as you suggest
> below.
>
> As for offline, I don't understand what the problem is.  You mentioned
> docker, which I haven't looked at much.  Why can't you have an image
> that was created from an overlaid Keycloak server?
>>    I don't really like the deployment overalys as it all feels a bit magical and black boxed.
> Don't you think it's better than telling them to hack our WAR?
>> 4.   I hate this - the user shouldn't have to explode the WAR and also it's in a really strange place for a user to find
> I hate it too.  I almost wish I hadn't implemented exploded mode.  I
> re-verified that it is working, btw.
I don't hate it as it provides at least "some way" to add providers in 
offline mode. It allows scripting too as there are just 2 commands 
needed in shell to unzip the WAR and copy the provider here. The 
locations sucks, but still.... it's better then force users to use CLI ;-)

Marek
>> 5.   That's not an option for the appliance
> You still could do it with the appliance if you wanted.
>
> But the idea of the appliance is that you shouldn't need to change it
> except through a UI.  That's where the overlay method will really shine,
> especially when we can get provider management into our own UI.  At that
> point, copying jars to a file system will look extremely primitive in
> comparison.
>> Maybe what we could do for now is to create add-provider.sh/bat scripts that makes it easier to do without any knowledge of CLI.
>>
>> Can we not use modules as Bill suggests? We could make the keycloak subsystem depend on a keycloak-providers module and users would register their provider modules there.
>>
>>> Why are these not sufficient?
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-user at lists.jboss.org
>>>>> Sent: Friday, 16 January, 2015 2:13:24 PM
>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>>> Keycloak 1.1 Beta-2
>>>>>
>>>>> On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: keycloak-user at lists.jboss.org
>>>>>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
>>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
>>>>>>> Keycloak 1.1 Beta-2
>>>>>>>
>>>>>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
>>>>>>>> How is a provider added using the CLI? I can't find any examples on
>>>>>>>> that.
>>>>>>> In the doc there is a step-by-step example of how to do it.  See section
>>>>>>> 3.4.2.2.
>>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>>> That example uses the CLI GUI, we need one that uses plain CLI
>>>>> Plain CLI is harder in this case.  CLI GUI lets you browse for the file
>>>>> you need.   Overall, plain CLI is a lot more error prone.
>>>>>
>>>>> If you do this once in CLI GUI then you will generate the CLI command
>>>>> that you can cut and paste into plain CLI or a script.  But if you want,
>>>>> I can include an example of that command.
>>>>>> There's also another issue with this approach, which I didn't stress
>>>>>> enough
>>>>>> last time around, it requires the server to be running to add providers.
>>>>>> That makes it much harder to for example create a Docker cartridge that
>>>>>> includes some custom providers.
>>>>> Perhaps we just need to document the fact that you can still explode the
>>>>> WAR and do it the old way?
>>>>>>>> Also, there are still several references in the docs and examples that
>>>>>>>> uses
>>>>>>>> the old approach of copying to WEB-INF/lib.
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>>>> To: keycloak-user at lists.jboss.org
>>>>>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
>>>>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar
>>>>>>>>> in
>>>>>>>>> Keycloak 1.1 Beta-2
>>>>>>>>>
>>>>>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
>>>>>>>>>
>>>>>>>>> See
>>>>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
>>>>>>>>>
>>>>>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I created a custom User Federation Provider and deployed it as per the
>>>>>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it
>>>>>>>>> appears
>>>>>>>>> that the location of Keycloak war in Wildfly has changed in 1.1 Beta-2
>>>>>>>>> version and it is no longer inflated. Can someone suggest where
>>>>>>>>> exactly
>>>>>>>>> I
>>>>>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Raghu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Fri Jan 16 12:26:25 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 16 Jan 2015 12:26:25 -0500 (EST)
Subject: [keycloak-dev] WebSocket integration
In-Reply-To: <54B93F65.4080202@redhat.com>
References: <54B93CDD.8060108@kroehling.de> <54B93F65.4080202@redhat.com>
Message-ID: <1919987632.10726900.1421429185299.JavaMail.zimbra@redhat.com>

Some time ago Shane and I were investigating WebSocket security using PicketLink [1] and JEE. Specially when using CDI [2].

Some references:

[1] https://issues.jboss.org/browse/PLINK-628
[2] https://issues.jboss.org/browse/CDI-370

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Friday, January 16, 2015 2:42:13 PM
Subject: Re: [keycloak-dev] WebSocket integration

Single page app would work with cookie and server side adapter.  I don't 
know how it would work with javascript.  You'd have to send the token 
with the HTTP Upgrade request.

On 1/16/2015 11:31 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> I'm investigating the possibility of protecting a WebSocket endpoint
> with Keycloak and I found out that it works out of the box with
> cookie-based authentication, meaning, the web page that opens the web
> socket client should itself be protected, so that the cookie is sent
> on the WebSocket request and authentication is made (confidential).
>
> In my target scenario, however, the web page is a single-page app
> (public) talking with a backend (bearer-only) in another host.
>
> So, I'd like to know if there's anything planned on the WebSockets
> front for such scenario. For instance, a JavaScript utility that
> handles the setup of the socket (either with a custom protocol, or an
> initial message with the bearer token, or another alternative) and a
> server counterpart for this.
>
> If there isn't yet, I'll probably have some time to explore this.
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUuTzdAAoJEDnJtskdmzLMgSIH/2eGoZSzUcsXL2zs7tyLEAIL
> LTHBOY0vlr3KDRIWMcab8ijIAKt5u+JQnb4fJlEEXW1C8+QKNSDJYsfj/HcGnDcg
> TM2kzhy4HS9O8CnlRqKEm6FlRKfgV3R/64huFXCRXmIdkxiKGgMQvmhWmlrDFHVy
> ZRtaNk3e433LkD4/fYdWIobjdtxZTv4xAglWAgXCAVdXJCy8Sp+yiopU7LNMqb75
> mgWk89h8U5nl/J9HuAd8+oZH9qg35lwI1LZOPRRwpyl4td4x1tDR2lQc1SJmS47g
> N2ES3jTtGHWMDEfsxDyLIQ6TmC1+r1Yoid51jILqaxlYGWgH/eRtnwny0Qczj+w=
> =x0ZO
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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 jpkroehling at redhat.com  Fri Jan 16 12:26:29 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 16 Jan 2015 18:26:29 +0100
Subject: [keycloak-dev] WebSocket integration
In-Reply-To: <54B93F65.4080202@redhat.com>
References: <54B93CDD.8060108@kroehling.de> <54B93F65.4080202@redhat.com>
Message-ID: <54B949C5.6030308@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/16/2015 05:42 PM, Bill Burke wrote:
> Single page app would work with cookie and server side adapter.  I
> don't know how it would work with javascript.  You'd have to send
> the token with the HTTP Upgrade request.

If the single-page app is deployed on the same host/context, yes. But
if it's deployed on a different host (possibly on a CDN), then it has
to be a public application, not a confidential. So, cookie wouldn't work.

As far as I know, the HTTP Upgrade is handled by the WebSocket
implementation on the browser, so, there's no opportunity to add a
custom header there via JavaScript.

The usual solution is to either use a custom protocol ("sub-protocol"
as per the spec) or to send the token on a first message. As this is a
boiler plate code that would be very similar to all applications being
protected by Keycloak, I was wondering if it wouldn't make sense to
implement this on Keycloak adapters directly.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUuUnFAAoJECKM1e+fkPrX9yYH/j/m2dFRCwP017xlDfQ5NaYs
5ieTpFH6MSxvpTWazr1MVigpk4VtBk/rYc6UHbYIOqAuX/6r3XGXwDLsP2g11GhT
GD2NzIylkp5TOVlLY9cwzWlF76APVqixXLRlqjj0OBuDeALQlkQSx1MlHkXi+D9L
z/SOpqkG+tkn7QMIMq14Juw25ro/AfzTjS4TlpblOyWtd2/Xj85T6z2MJHK6tw8j
n29eQTP1BrIx8J+ShPz7jNxh8d6S2R1RqpDccYWYCc6ca5zi1xIEh7fH3DemRp27
/2R+3HYfaEUXyHWCMhs2fLwRW9KN65oWDWWN2KahYaWXxjHx82GsLDT6hFinz/s=
=sjeh
-----END PGP SIGNATURE-----

From mposolda at redhat.com  Fri Jan 16 12:49:23 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 16 Jan 2015 18:49:23 +0100
Subject: [keycloak-dev] Direct grant API enable/disable on per-app
 instead of realm
In-Reply-To: <1192534252.10933598.1421336295727.JavaMail.zimbra@redhat.com>
References: <488356343.10760306.1421323225531.JavaMail.zimbra@redhat.com>	<54B7DA5F.8070109@redhat.com>
	<1192534252.10933598.1421336295727.JavaMail.zimbra@redhat.com>
Message-ID: <54B94F23.1090802@redhat.com>

On 15.1.2015 16:38, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 15 January, 2015 4:18:55 PM
>> Subject: Re: [keycloak-dev] Direct grant API enable/disable on per-app instead of realm
>>
>> I don't know...Once you have one public client that supports direct
>> grants with a large enough scope, there's your attack vector.
> Well, sure if you enable if for a public client with the full scope it doesn't make much difference. But, currently you can't limit it at all other than turning it off completely.
>
> Also, another thing is that currently we require a redirect-uri to be registered for an app, but that shouldn't be required if an app only uses the direct grant.
+1, We allow to specify it for oauth client though, but oauth client 
doesn't have it's own roles. So usually if you have oauth client with 
"direct grants only" enabled, you need to give him some scopes to other 
existing application or realm roles, which makes it even less safe.

Also similar case is for recently added Basic authentication support. 
When I have rest application, which should allow to authenticate my rest 
endpoints either with "bearer" or "basic" authentication, it shouldn't 
be needed to have redirect-uri configured for this application. 
Currently it's needed.

IMO we can easily fix it if we allow basic authentication for 
"bearer-only" applications too (as long as they have "enable-basic-auth" 
in adapter config). My understanding of "Bearer only application" is 
kind of application, which can't request it's own access token, but just 
allow rest authentication. So I am not seeing issue with allowing basic 
auth for it.

Marek
>
>>
>> On 1/15/2015 7:00 AM, Stian Thorgersen wrote:
>>> I propose we move the "Direct Grant API" enable/disable from the realm and
>>> add it to applications/clients instead. This allows greater control over
>>> what is exposed using the direct grant api.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri Jan 16 14:26:38 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Jan 2015 14:26:38 -0500
Subject: [keycloak-dev] WebSocket integration
In-Reply-To: <1919987632.10726900.1421429185299.JavaMail.zimbra@redhat.com>
References: <54B93CDD.8060108@kroehling.de> <54B93F65.4080202@redhat.com>
	<1919987632.10726900.1421429185299.JavaMail.zimbra@redhat.com>
Message-ID: <54B965EE.9070200@redhat.com>

It doesn't look like you can send any header with the HTTP Upgrade 
request done by the browser.  It could be done by sending the token with 
the WebSocket connect url as a query param.  This would have to be a 
one-off highly constrained token though.

On 1/16/2015 12:26 PM, Pedro Igor Silva wrote:
> Some time ago Shane and I were investigating WebSocket security using PicketLink [1] and JEE. Specially when using CDI [2].
>
> Some references:
>
> [1] https://issues.jboss.org/browse/PLINK-628
> [2] https://issues.jboss.org/browse/CDI-370
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, January 16, 2015 2:42:13 PM
> Subject: Re: [keycloak-dev] WebSocket integration
>
> Single page app would work with cookie and server side adapter.  I don't
> know how it would work with javascript.  You'd have to send the token
> with the HTTP Upgrade request.
>
> On 1/16/2015 11:31 AM, Juraci Paix?o Kr?hling wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> All,
>>
>> I'm investigating the possibility of protecting a WebSocket endpoint
>> with Keycloak and I found out that it works out of the box with
>> cookie-based authentication, meaning, the web page that opens the web
>> socket client should itself be protected, so that the cookie is sent
>> on the WebSocket request and authentication is made (confidential).
>>
>> In my target scenario, however, the web page is a single-page app
>> (public) talking with a backend (bearer-only) in another host.
>>
>> So, I'd like to know if there's anything planned on the WebSockets
>> front for such scenario. For instance, a JavaScript utility that
>> handles the setup of the socket (either with a custom protocol, or an
>> initial message with the bearer token, or another alternative) and a
>> server counterpart for this.
>>
>> If there isn't yet, I'll probably have some time to explore this.
>>
>> - - Juca.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJUuTzdAAoJEDnJtskdmzLMgSIH/2eGoZSzUcsXL2zs7tyLEAIL
>> LTHBOY0vlr3KDRIWMcab8ijIAKt5u+JQnb4fJlEEXW1C8+QKNSDJYsfj/HcGnDcg
>> TM2kzhy4HS9O8CnlRqKEm6FlRKfgV3R/64huFXCRXmIdkxiKGgMQvmhWmlrDFHVy
>> ZRtaNk3e433LkD4/fYdWIobjdtxZTv4xAglWAgXCAVdXJCy8Sp+yiopU7LNMqb75
>> mgWk89h8U5nl/J9HuAd8+oZH9qg35lwI1LZOPRRwpyl4td4x1tDR2lQc1SJmS47g
>> N2ES3jTtGHWMDEfsxDyLIQ6TmC1+r1Yoid51jILqaxlYGWgH/eRtnwny0Qczj+w=
>> =x0ZO
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From bburke at redhat.com  Fri Jan 16 14:27:58 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 16 Jan 2015 14:27:58 -0500
Subject: [keycloak-dev] Direct grant API enable/disable on per-app
 instead of realm
In-Reply-To: <54B94F23.1090802@redhat.com>
References: <488356343.10760306.1421323225531.JavaMail.zimbra@redhat.com>	<54B7DA5F.8070109@redhat.com>
	<1192534252.10933598.1421336295727.JavaMail.zimbra@redhat.com>
	<54B94F23.1090802@redhat.com>
Message-ID: <54B9663E.9040304@redhat.com>

If you set "bearer-only" you don't have to enter in a redirect URI.

On 1/16/2015 12:49 PM, Marek Posolda wrote:
> On 15.1.2015 16:38, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 15 January, 2015 4:18:55 PM
>>> Subject: Re: [keycloak-dev] Direct grant API enable/disable on
>>> per-app instead of realm
>>>
>>> I don't know...Once you have one public client that supports direct
>>> grants with a large enough scope, there's your attack vector.
>> Well, sure if you enable if for a public client with the full scope it
>> doesn't make much difference. But, currently you can't limit it at all
>> other than turning it off completely.
>>
>> Also, another thing is that currently we require a redirect-uri to be
>> registered for an app, but that shouldn't be required if an app only
>> uses the direct grant.
> +1, We allow to specify it for oauth client though, but oauth client
> doesn't have it's own roles. So usually if you have oauth client with
> "direct grants only" enabled, you need to give him some scopes to other
> existing application or realm roles, which makes it even less safe.
>
> Also similar case is for recently added Basic authentication support.
> When I have rest application, which should allow to authenticate my rest
> endpoints either with "bearer" or "basic" authentication, it shouldn't
> be needed to have redirect-uri configured for this application.
> Currently it's needed.
>
> IMO we can easily fix it if we allow basic authentication for
> "bearer-only" applications too (as long as they have "enable-basic-auth"
> in adapter config). My understanding of "Bearer only application" is
> kind of application, which can't request it's own access token, but just
> allow rest authentication. So I am not seeing issue with allowing basic
> auth for it.
>
> Marek
>>
>>>
>>> On 1/15/2015 7:00 AM, Stian Thorgersen wrote:
>>>> I propose we move the "Direct Grant API" enable/disable from the
>>>> realm and
>>>> add it to applications/clients instead. This allows greater control
>>>> over
>>>> what is exposed using the direct grant api.
>>>> _______________________________________________
>>>> 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 bburke at redhat.com  Sat Jan 17 10:18:55 2015
From: bburke at redhat.com (Bill Burke)
Date: Sat, 17 Jan 2015 10:18:55 -0500
Subject: [keycloak-dev] Fwd:Resteasy and Vert.x
In-Reply-To: <CADSBNAjQEgPsDi_UA1X6PMOYNC3+F-3rHAfve+_bRR9Trd-fww@mail.gmail.com>
References: <CADSBNAjQEgPsDi_UA1X6PMOYNC3+F-3rHAfve+_bRR9Trd-fww@mail.gmail.com>
Message-ID: <54BA7D5F.3010708@redhat.com>

Somebody created a vertx adapter for resteasy.


-------- Forwarded Message --------
Subject: 	[Resteasy-users] Resteasy and Vert.x
Date: 	Fri, 16 Jan 2015 17:49:16 +0100
From: 	Kristoffer Sj?gren <stoffe at gmail.com>
To: 	resteasy-users at lists.sourceforge.net



Hi

I have created a project called vertxrs which support JAX-RS over Vert.x.?

This is the embedded version of Vert.x which use Resteasy as the
implementation of JAX-RS.

https://github.com/deephacks/vertxrs

The jars should be in Maven Central at any moment.

Enjoy,
-Kristoffer

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



From james.scicluna at qhrtech.com  Sat Jan 17 12:43:58 2015
From: james.scicluna at qhrtech.com (James Scicluna)
Date: Sat, 17 Jan 2015 17:43:58 +0000
Subject: [keycloak-dev] Importing users to Keycloak
Message-ID: <AD791BD1-AE4A-4E1F-9311-D329F579DF49@qhrtech.com>

Hello Keycloak Team,
at Medeo we are currently evaluating the possibility of using Keycloak as our authorization provider. In particular we are very excited about the comprehensive feature set that Keycloak offers.

Our users (and authorization) are currently handled by our main application but we want to move them out to a separate authorization provider for SSO. So far we thought about doing this in two ways:
- replicate our database, connect it to Keycloak and implement the matching hashing algorithms for user passwords
- federate the users to our existing database

Are these two plausible solutions? And, are there any other possible solutions?

Thank you

--
James Scicluna
SOFTWARE ENGINEER

[cid:028E41F2-51B2-462F-BD26-73EFE5C31630]


Stay Healthy.
@medeo<http://twitter.com/medeo>

Office +1 888-297-2973
Fax +1 604-608-9761

For Health Providers medeohealth.com<http://www.medeohealth.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150117/6cec5bbe/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: medeo-logo.png
Type: image/png
Size: 2410 bytes
Desc: medeo-logo.png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150117/6cec5bbe/attachment-0001.png 

From christian.beikov at gmail.com  Sun Jan 18 19:14:11 2015
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 19 Jan 2015 01:14:11 +0100
Subject: [keycloak-dev] Direct links to pages
Message-ID: <54BC4C53.2050300@gmail.com>

Hello!

Quick question. Is there a way to directly link to the registration or 
login page from a different page?
I tried the following but only get "Bad request" when submitting the form.

Registration: 
/auth/realms/{realm-name}/tokens/registrations?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fprotected&client_id=protected
Login: 
/auth/realms/{realm-name}/tokens/login?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fprotected&client_id=protected
-- 

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150119/db889970/attachment.html 

From christian.beikov at gmail.com  Sun Jan 18 19:56:59 2015
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 19 Jan 2015 01:56:59 +0100
Subject: [keycloak-dev] Access original session
In-Reply-To: <792210726.2563607.1420184087778.JavaMail.zimbra@redhat.com>
References: <549FD512.9020705@gmail.com>
	<349569894.2249184.1419943101421.JavaMail.zimbra@redhat.com>
	<54A29E59.7030008@gmail.com>
	<1057182580.2251047.1419944384069.JavaMail.zimbra@redhat.com>
	<54A2BAE4.2050007@gmail.com>
	<792210726.2563607.1420184087778.JavaMail.zimbra@redhat.com>
Message-ID: <54BC565B.8030702@gmail.com>

For the sake of completeness, here is the bug that actually was the 
reason for my problems: https://issues.jboss.org/browse/UNDERTOW-350

Since my application was deployed to the root context, the path of the 
session cookie was set to a wrong value.
A quick workaround is to set the path in a servlet context 
listener(seems like web.xml config is not used, I'll file a bug for that 
when I have some time) like that:

public class ConfigServletContextListener implements 
ServletContextListener {

     @Override
     public void contextInitialized(ServletContextEvent sce) {
         ServletContext sc = sce.getServletContext();
sc.setSessionTrackingModes(EnumSet.of(SessionTrackingMode.COOKIE));
         sc.getSessionCookieConfig().setPath("/");
     }

     @Override
     public void contextDestroyed(ServletContextEvent sce) {
     }

}

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 02.01.2015 um 08:34 schrieb Stian Thorgersen:
>
> ----- Original Message -----
>> From: "Christian Beikov" <christian.beikov at gmail.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 30 December, 2014 3:47:00 PM
>> Subject: Re: [keycloak-dev] Access original session
>>
>> I am using the following versions:
>>
>>    * Keycloak 1.0.4.Final
>>    * Wildfly 8.1.0.Final
>>
>> Also it doesn't respect the cookie settings of the web.xml. I tried to
>> configure a different name for the cookie just to test it, but it didn't
>> change. When navigating to "/whatever.xhtml" I suddenly get the
>> configured cookie set.
>> It seems as if the Keycloak adapters wrap the HttpServletRequest to
>> expose a different session map when working with secured resources.
>> Which demo are you talking about? I would love to try it out so that I
>> can confirm if it has something to do with my setup or Keycloak.
> Keycloak should just be using the underlying http session and not do anything special to it. Do you have the same problem with HTTP basic?
>
> The demo I'm referring to is the one that is bundled with the download, it's in examples/preconfigured-demo
>
>> Mit freundlichen Gr??en,
>> ------------------------------------------------------------------------
>> *Christian Beikov*
>> Am 30.12.2014 um 13:59 schrieb Stian Thorgersen:
>>> ----- Original Message -----
>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 30 December, 2014 1:45:13 PM
>>>> Subject: Re: [keycloak-dev] Access original session
>>>>
>>>> Seems like my question wasn't clear enough.
>>>>
>>>> I have the following config in my web.xml
>>>>
>>>>        <security-constraint>
>>>>            <web-resource-collection>
>>>> <web-resource-name>Protected</web-resource-name>
>>>>                <url-pattern>/protected/*</url-pattern>
>>>>            </web-resource-collection>
>>>>            <auth-constraint>
>>>>                <role-name>user</role-name>
>>>>            </auth-constraint>
>>>>        </security-constraint>
>>>>
>>>>        <login-config>
>>>>            <auth-method>KEYCLOAK</auth-method>
>>>>            <realm-name>portfolio-webapp</realm-name>
>>>>        </login-config>
>>>>
>>>>        <security-role>
>>>>            <role-name>user</role-name>
>>>>        </security-role>
>>>>
>>>> Now when I navigate to e.g. "/protected/index.xhtml" I get redirected to
>>>> the Keycloak login. Unfortunately, the cookie which is set by the
>>>> Keycloak adapters after a succesful login, has the path "/protected"
>>>> set. When I navigate to "/whatever.xhtml" I obviously have no access to
>>>> the cookie since the browser doesn't send it.
>>>>
>>>> How am I supposed to access the logged in user outside of the protected
>>>> area?
>>>>
>>>> The session cookie (assuming you're talking about JSESSIONID) should be
>>>> set
>>>> to the context-path of your WAR not a specific protected resource.
>>>>
>>>> Unfortunately I am experiencing that it is set to a different path.
>>> Strange. I've just tried with our demo, which has a similar
>>> security-constraint to yours, and it sets it to the context-path of the
>>> WAR as expected.
>>>
>>> Keycloak doesn't set this cookie itself, that's sorted by the JEE
>>> container. Which Keycloak version and JEE server are you using?
>>>
>>>> Is your protected resources in the same WAR as the unprotected resources?
>>>>
>>>> Yes, it's all in the same WAR.
>>>>
>>>> Mit freundlichen Gr??en,
>>>> ------------------------------------------------------------------------
>>>> *Christian Beikov*
>>>> Am 30.12.2014 um 13:38 schrieb Stian Thorgersen:
>>>>> The session cookie (assuming you're talking about JSESSIONID) should be
>>>>> set
>>>>> to the context-path of your WAR not a specific protected resource. Is
>>>>> your
>>>>> protected resources in the same WAR as the unprotected resources?
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Christian Beikov" <christian.beikov at gmail.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Sunday, 28 December, 2014 11:01:54 AM
>>>>>> Subject: [keycloak-dev] Access original session
>>>>>>
>>>>>> Hello there!"
>>>>>>
>>>>>> I have an application that has protected resources on the pattern
>>>>>> "/protected/*" and I receive a session cookie for the path "/protected",
>>>>>> which makes sense. Now my problem is, that I want the path of the cookie
>>>>>> to
>>>>>> be "/" so I can access the user information even outside of the
>>>>>> protected
>>>>>> resources.
>>>>>> Since I think this might introduce some problems, the only other way to
>>>>>> realize that I could think of is, to get access to the underlying
>>>>>> servlet
>>>>>> session. Not only would that session have to be created properly, which
>>>>>> I
>>>>>> am
>>>>>> not sure is happening when browsing in the protected resources, I would
>>>>>> also
>>>>>> need to access it on the server, so that I can save the currently logged
>>>>>> in
>>>>>> user into it.
>>>>>>
>>>>>> Is there a possibility to access the servlet session within the Keycloak
>>>>>> context? If so, could you please share some code or point me to an API?
>>>>>> --
>>>>>>
>>>>>> Mit freundlichen Gr??en,
>>>>>>
>>>>>> Christian Beikov
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20150119/98d9d1c4/attachment.html 

From stian at redhat.com  Mon Jan 19 02:42:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 Jan 2015 02:42:31 -0500 (EST)
Subject: [keycloak-dev] [keycloak-user] Location of User Federation
 Provider jar in Keycloak 1.1 Beta-2
In-Reply-To: <54B93F57.9070303@redhat.com>
References: <111594417.61123.1421322414729.JavaMail.yahoo@jws100116.mail.ne1.yahoo.com>
	<54B821D4.8040202@redhat.com>
	<1646813976.11298197.1421392775305.JavaMail.zimbra@redhat.com>
	<54B90E74.9040704@redhat.com>
	<340510006.11473992.1421417272996.JavaMail.zimbra@redhat.com>
	<54B91E22.4060808@redhat.com>
	<651223121.11549801.1421421438944.JavaMail.zimbra@redhat.com>
	<54B93F57.9070303@redhat.com>
Message-ID: <1847485038.12207722.1421653351447.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 January, 2015 5:41:59 PM
> Subject: Re: [keycloak-user] Location of User Federation Provider jar in Keycloak 1.1 Beta-2
> 
> On 1/16/2015 10:17 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 16 January, 2015 3:20:18 PM
> >> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
> >> Keycloak 1.1 Beta-2
> >>
> >> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
> >>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down
> >>> to
> >>> this issue. I should have raised it before, but it completely slipped my
> >>> mind :(
> >> We did talk about this at great length before.   I tried and tried to
> >> preserve the "drop it in the file system" approach.  It just plain won't
> >> work for domains.
> > I know we did, but I like changing my mind ;)
> >
> >>> IMO we need:
> >>>
> >>> 1. A usable way to deploy a provider without using the CLI GUI
> >>> 2. Ideally be able to deploy a provider with an offline server
> >> We have 5 ways to add a provider:
> >> 1. CLI
> >> 2. CLI GUI
> >> 3. CLI script
> >> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib
> >> 5. Use the war dist and do it the old way.
> > 1-3. If the CLI was easy to use that would work, except we also need to be
> > able to do it offline.
> We can ship a script that makes this task a little easier as you suggest
> below.
> 
> As for offline, I don't understand what the problem is.  You mentioned
> docker, which I haven't looked at much.  Why can't you have an image
> that was created from an overlaid Keycloak server?

There's two ways to create a Docker image, the most common is to use a DockerFile that can installs and configures things. Copying a file is a simple one-liner, while starting the server, waiting for it to be in a certain state and invoking the CLI is a hole different thing. You also don't want to do this really as it adds entries to the log files, initiates db, all that kinds stuff that shouldn't be in the "base" image.

Then there's another issue and that is providers that are used by Keycloak during startup. For example to replace the db with something custom the user first has to start the server with one of the built-in adapters. I could see this ending up in a situation where the server doesn't start with the current provider and a user wants to add a custom one, but can't as they can't start the server.

> >   I don't really like the deployment overalys as it all feels a bit magical
> >   and black boxed.
> Don't you think it's better than telling them to hack our WAR?

Adding a JAR to a folder is simple. Deployment overlays just doesn't give the user the feeling of being in control IMO. Maybe that's just be not understanding the feature.

> > 4.   I hate this - the user shouldn't have to explode the WAR and also it's
> > in a really strange place for a user to find
> I hate it too.  I almost wish I hadn't implemented exploded mode.  I
> re-verified that it is working, btw.
> > 5.   That's not an option for the appliance
> You still could do it with the appliance if you wanted.

I'm not sure what you're saying here, are you suggesting a user dl the appliance and the war dist as well?

> 
> But the idea of the appliance is that you shouldn't need to change it
> except through a UI.  That's where the overlay method will really shine,
> especially when we can get provider management into our own UI.  At that
> point, copying jars to a file system will look extremely primitive in
> comparison.

I don't agree with that. The idea of the appliance is that it should work OOTB and it should be easy to do any changes you need. Even if we had a very sleek way of uploading providers through the admin console, we'd still not to be able to do it from the command-line.

> >
> > Maybe what we could do for now is to create add-provider.sh/bat scripts
> > that makes it easier to do without any knowledge of CLI.
> >
> > Can we not use modules as Bill suggests? We could make the keycloak
> > subsystem depend on a keycloak-providers module and users would register
> > their provider modules there.
> >
> >> Why are these not sufficient?
> >>> ----- Original Message -----
> >>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-user at lists.jboss.org
> >>>> Sent: Friday, 16 January, 2015 2:13:24 PM
> >>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar in
> >>>> Keycloak 1.1 Beta-2
> >>>>
> >>>> On 1/16/2015 2:19 AM, Stian Thorgersen wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> Cc: keycloak-user at lists.jboss.org
> >>>>>> Sent: Thursday, 15 January, 2015 9:23:48 PM
> >>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider jar
> >>>>>> in
> >>>>>> Keycloak 1.1 Beta-2
> >>>>>>
> >>>>>> On 1/15/2015 9:29 AM, Stian Thorgersen wrote:
> >>>>>>> How is a provider added using the CLI? I can't find any examples on
> >>>>>>> that.
> >>>>>> In the doc there is a step-by-step example of how to do it.  See
> >>>>>> section
> >>>>>> 3.4.2.2.
> >>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
> >>>>> That example uses the CLI GUI, we need one that uses plain CLI
> >>>> Plain CLI is harder in this case.  CLI GUI lets you browse for the file
> >>>> you need.   Overall, plain CLI is a lot more error prone.
> >>>>
> >>>> If you do this once in CLI GUI then you will generate the CLI command
> >>>> that you can cut and paste into plain CLI or a script.  But if you want,
> >>>> I can include an example of that command.
> >>>>> There's also another issue with this approach, which I didn't stress
> >>>>> enough
> >>>>> last time around, it requires the server to be running to add
> >>>>> providers.
> >>>>> That makes it much harder to for example create a Docker cartridge that
> >>>>> includes some custom providers.
> >>>> Perhaps we just need to document the fact that you can still explode the
> >>>> WAR and do it the old way?
> >>>>>>> Also, there are still several references in the docs and examples
> >>>>>>> that
> >>>>>>> uses
> >>>>>>> the old approach of copying to WEB-INF/lib.
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>>>>>> To: keycloak-user at lists.jboss.org
> >>>>>>>> Sent: Thursday, 15 January, 2015 2:09:56 PM
> >>>>>>>> Subject: Re: [keycloak-user] Location of User Federation Provider
> >>>>>>>> jar
> >>>>>>>> in
> >>>>>>>> Keycloak 1.1 Beta-2
> >>>>>>>>
> >>>>>>>> Providers are now uploaded using WildFly CLI or CLI GUI.
> >>>>>>>>
> >>>>>>>> See
> >>>>>>>> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/server-installation.html#d4e350
> >>>>>>>>
> >>>>>>>> On 1/15/2015 6:46 AM, prab rrrr wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I created a custom User Federation Provider and deployed it as per
> >>>>>>>> the
> >>>>>>>> documentation. It worked in earlier versions (1.1 Beta-1) but it
> >>>>>>>> appears
> >>>>>>>> that the location of Keycloak war in Wildfly has changed in 1.1
> >>>>>>>> Beta-2
> >>>>>>>> version and it is no longer inflated. Can someone suggest where
> >>>>>>>> exactly
> >>>>>>>> I
> >>>>>>>> have to place the Federation provider jar in 1.1 Beta-2 version?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Raghu
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> keycloak-user mailing list keycloak-user at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> keycloak-user mailing list
> >>>>>>>> keycloak-user at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> 
> 

From stian at redhat.com  Mon Jan 19 02:59:35 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 19 Jan 2015 02:59:35 -0500 (EST)
Subject: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
In-Reply-To: <54B92142.7010407@redhat.com>
References: <1734324363.10043953.1421340371819.JavaMail.zimbra@redhat.com>
	<585656770.10112298.1421343641104.JavaMail.zimbra@redhat.com>
	<54B80FEA.8060704@redhat.com>
	<106136572.10561573.1421415005955.JavaMail.zimbra@redhat.com>
	<1597917021.11473783.1421417230594.JavaMail.zimbra@redhat.com>
	<54B92142.7010407@redhat.com>
Message-ID: <528650035.12211608.1421654375155.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 16 January, 2015 3:33:38 PM
> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> 
> 
> 
> On 1/16/2015 9:07 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 16 January, 2015 2:30:05 PM
> >> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, January 15, 2015 5:07:22 PM
> >>> Subject: Re: [keycloak-dev] KEYCLOAK-884 - UserInfo Endpoint
> >>>
> >>>
> >>>
> >>> On 1/15/2015 12:40 PM, Pedro Igor Silva wrote:
> >>>> ----- Original Message -----
> >>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>> Sent: Thursday, January 15, 2015 2:46:11 PM
> >>>>> Subject: KEYCLOAK-884 - UserInfo Endpoint
> >>>>>
> >>>>> Bill,
> >>>>>
> >>>>>       Is the work you are doing for claims considering the respective
> >>>>>       sections
> >>>>>       in OpenID Connect specification ? To be more specific,
> >>>>>       http://openid.net/specs/openid-connect-core-1_0.html#Claims.
> >>>>>
> >>>>>       Depending on what you are doing, I think I would need to wait you
> >>>>>       finish
> >>>>>       in order to full support what is expected from the UserInfo
> >>>>>       endpoint.
> >>>>>       Meanwhile, I'm already doing everything that is necessary to get
> >>>>>       the
> >>>>>       endpoint up and running with a basic interoperability based on
> >>>>>       the
> >>>>>       default scope values used to request claims (profile, email,
> >>>>>       address,
> >>>>>       phone).
> >>>>>
> >>>>>       Btw, are you planning to configure any type of configuration in
> >>>>>       order
> >>>>>       to
> >>>>>       setup the privacy of certain claims ?
> >>>>
> >>>> Forget about it. Just noticed you already have support for that.
> >>>>
> >>>
> >>> Nothing beyond a few claims though.  Can't enter in address, phone,
> >>> etc...
> >>
> >> I've submitted a PR for this issue. There are some changes to IDToken type
> >> that would like to share and discuss.
> >>
> >> Today, user claims are strongly tied with the IDToken type. They are there
> >> as
> >> properties of the type itself. From a token perspective, that is how they
> >> are represented but from an internal perspective I think we can improve it
> >> a
> >> little bit by introducing a specific type for user claims.
> >>
> >> IMO, a best design is to extract those specific claims from IDToken type
> >> and
> >> get them into a specific UserClaimSet, which also helps to avoid code
> >> duplication when claims are needed in different places. Just like we need
> >> it
> >> in UserInfo.
> >>
> >> That allow us to better represent/manage user claims internally and keep
> >> things more in sync with the specs, without break anything from a token
> >> representation or functionality perspective.
> >
> > I'm not convinced about this. Other than IDToken and UserInfo endpoint I
> > can't see any uses for this.
> >
> > Also, I reckon this will change a fair bit by introducing custom user
> > profiles. Internally I reckon we'll be using user profiles, not claim-set.
> >
> 
> My plan was the following:
> 
> Current UserModel.attributes will be used for internal bookkeeping only.
>   Going to add a new "UserProfileType", "UserProfileValue" (name TBD)

Should it not be ProfileAttributeType and ProfileAttributeValue?

> type that contains:
> 
> UserProfileType:
> * id
> * name
> * .css type
> * type (bool, int, date, etc.)
> * boolean displayOnRegistrationPage
> 
> Question, do I need a .css id to plug in a value too?  How would we
> display the german label name for "phone"?

What's the .css type for?

For internationalization it's best that there's a central place to provide translations rather than it being scattered all over the place. Everything that is displayed to end-users should support two types of values. A name or a key. Does that doesn't need internationalization can just specify the name directly, but to use internationalization a key is entered instead (for example ${myAppName}). The key would then be resolved from the message bundle corresponding to the required language.

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

From mposolda at redhat.com  Mon Jan 19 03:08:32 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 19 Jan 2015 09:08:32 +0100
Subject: [keycloak-dev] Direct grant API enable/disable on per-app
 instead of realm
In-Reply-To: <54B9663E.9040304@redhat.com>
References: <488356343.10760306.1421323225531.JavaMail.zimbra@redhat.com>	<54B7DA5F.8070109@redhat.com>
	<1192534252.10933598.1421336295727.JavaMail.zimbra@redhat.com>
	<54B94F23.1090802@redhat.com> <54B9663E.9040304@redhat.com>
Message-ID: <54BCBB80.4020001@redhat.com>

Sure, but if you set "bearer-only" you can't currently use basic 
authentication for your rest endpoint: 
https://github.com/keycloak/keycloak/blob/master/integration/adapter-core/src/main/java/org/keycloak/adapters/RequestAuthenticator.java#L55 
and basic is checked on line 61.

So if you have rest application and you want it to support basic+bearer 
authentication for the rest endpoint, you actually can't use bearer-only 
for such application and hence you need to enter redirect URI for it. 
Even if you don't need it.

To address this, I would suggest minor change in RequestAuthenticator, 
so if my application is bearer-only and I have this in my keycloak.json:
"bearer-only": true,
"enable-basic-auth" : true

then it will allow both bearer+basic authentication.

Second change to suggest would be to support "Direct grants only" switch 
for applications too, not just for oauth clients.

Marek

On 16.1.2015 20:27, Bill Burke wrote:
> If you set "bearer-only" you don't have to enter in a redirect URI.
>
> On 1/16/2015 12:49 PM, Marek Posolda wrote:
>> On 15.1.2015 16:38, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 15 January, 2015 4:18:55 PM
>>>> Subject: Re: [keycloak-dev] Direct grant API enable/disable on
>>>> per-app instead of realm
>>>>
>>>> I don't know...Once you have one public client that supports direct
>>>> grants with a large enough scope, there's your attack vector.
>>> Well, sure if you enable if for a public client with the full scope it
>>> doesn't make much difference. But, currently you can't limit it at all
>>> other than turning it off completely.
>>>
>>> Also, another thing is that currently we require a redirect-uri to be
>>> registered for an app, but that shouldn't be required if an app only
>>> uses the direct grant.
>> +1, We allow to specify it for oauth client though, but oauth client
>> doesn't have it's own roles. So usually if you have oauth client with
>> "direct grants only" enabled, you need to give him some scopes to other
>> existing application or realm roles, which makes it even less safe.
>>
>> Also similar case is for recently added Basic authentication support.
>> When I have rest application, which should allow to authenticate my rest
>> endpoints either with "bearer" or "basic" authentication, it shouldn't
>> be needed to have redirect-uri configured for this application.
>> Currently it's needed.
>>
>> IMO we can easily fix it if we allow basic authentication for
>> "bearer-only" applications too (as long as they have "enable-basic-auth"
>> in adapter config). My understanding of "Bearer only application" is
>> kind of application, which can't request it's own access token, but just
>> allow rest authentication. So I am not seeing issue with allowing basic
>> auth for it.
>>
>> Marek
>>>
>>>>
>>>> On 1/15/2015 7:00 AM, Stian Thorgersen wrote:
>>>>> I propose we move the "Direct Grant API" enable/disable from the
>>>>> realm and
>>>>> add it to applications/clients instead. This allows greater control
>>>>> over
>>>>> what is exposed using the direct grant api.
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>> -- 
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


From mposolda at redhat.com  Mon Jan 19 03:36:35 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 19 Jan 2015 09:36:35 +0100
Subject: [keycloak-dev] Importing users to Keycloak
In-Reply-To: <AD791BD1-AE4A-4E1F-9311-D329F579DF49@qhrtech.com>
References: <AD791BD1-AE4A-4E1F-9311-D329F579DF49@qhrtech.com>
Message-ID: <54BCC213.1060708@redhat.com>

On 17.1.2015 18:43, James Scicluna wrote:
> Hello Keycloak Team,
> at Medeo we are currently evaluating the possibility of using Keycloak 
> as our authorization provider. In particular we are very excited about 
> the comprehensive feature set that Keycloak offers.
>
> Our users (and authorization) are currently handled by our main 
> application but we want to move them out to a separate authorization 
> provider for SSO. So far we thought about doing this in two ways:
> - replicate our database, connect it to Keycloak and implement the 
> matching hashing algorithms for user passwords
> - federate the users to our existing database
>
> Are these two plausible solutions? And, are there any other possible 
> solutions?
Yes, I would probably go with the second approach . You can implement 
your own UserFederationProvider and point it to your database: 
http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/user_federation.html 
. Then you can import your users either "on demand" (at the point they 
authenticate or someone search for them from keycloak admin console) or 
sync them all at once.

Marek
>
> Thank you
>
> -- 
> *James Scicluna*
> SOFTWARE ENGINEER
>
>
>
> Stay Healthy.
> @medeo <http://twitter.com/medeo>
>
> Office +1 888-297-2973
> Fax +1 604-608-9761
>
> *For Health Providers* _medeohealth.com <http://www.medeohealth.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/20150119/ec6a5f99/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2410 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150119/ec6a5f99/attachment-0001.png 

From juan.escot at cdtec.es  Tue Jan 20 05:46:36 2015
From: juan.escot at cdtec.es (Juan Escot)
Date: Tue, 20 Jan 2015 11:46:36 +0100
Subject: [keycloak-dev] Rest Service authentication.
Message-ID: <CALjk8zy0Sx=d_=aP9t5fm=KLrVE2rMQ+qmtDGTsQWFTT=Y8Lbw@mail.gmail.com>

Hi,
I'm developing an application with AngularJS and Rest Services. I'm using
Keycloak for authentication and role management.

Mi Angular project is registered as 'confidential' and work's fine. It
refresh tokens and sends it on header like this: 'Authorization:Bearer
eyJhbGciOiJSUzI1Ni...'

Mi java project is defined as 'bearer only' and it's developed with Java
EJBs as Rest Services. I need more control over permissions and roles, so I
don't want to secure my project with  security-contraints at web.xml. I'd
like to get user info and roles inside my Rest methods from token received.
I have checked I received the token with this line:

String token = request.getHeader("authorization");

But, I can't get any additional information about user. I have tried
different approaches but I can't fin a solution. Could I have a Keycloak
object with user info?.

This is a fragment of my code with all my attemps:

@Stateless
@LocalBean
@Path("/promociones")
@SecurityDomain("keycloak")
public class PromocionRest  {
    @Context
    HttpServletRequest request;

    @Context
    SecurityContext securityContext;

@Resource
SessionContext sc;

@GET
@Produces("application/json")
@Path("/list")
//@RolesAllowed({ "user" }) <-- If I use this annotation y get an error.
@PermitAll
public RespuestaListaBase<Promocion> listadoPromociones(...){
 KeycloakPrincipal principal =
(KeycloakPrincipal)securityContext.getUserPrincipal();
  KeycloakSecurityContext session = (KeycloakSecurityContext)
request.getAttribute(KeycloakSecurityContext.class.getName());
 if (sc!=null && sc.getCallerPrincipal()!=null){
System.out.println("Principal's name according to EJB: " +
sc.getCallerPrincipal().getName());
}

        System.out.println("Is user in role 'user'? " +
request.isUserInRole("user"));

        String token = request.getHeader("authorization");

        HttpClient client = new
HttpClientBuilder().disableTrustManager().build();
try {
String url = request.getRequestURL().toString();
        url = url.substring(0, url.indexOf('/', 8));

        HttpGet get = new HttpGet(url + "/auth/admin/realms/demo/roles");
    get.addHeader("Authorization", "Bearer " + token);
    try {
        HttpResponse response = client.execute(get);
        if (response.getStatusLine().getStatusCode() != 200) {
            //throw new Failure(response.getStatusLine().getStatusCode());
        }
        HttpEntity entity = response.getEntity();
        InputStream is = entity.getContent();

    } catch (IOException e) {
        throw new RuntimeException(e);
    }
} finally {
    client.getConnectionManager().shutdown();
}
}
}

I also have configured jboss-web.xml like this:
<jboss-web>
    <security-domain>keycloak</security-domain>
</jboss-web>

And web.xml like this:
    <login-config>
        <auth-method>KEYCLOAK</auth-method>
        <realm-name>demo</realm-name>
    </login-config>

    <security-role>
        <role-name>user</role-name>
    </security-role>

Some notes about the code:
- KeycloakPrincipal principal =
(KeycloakPrincipal)securityContext.getUserPrincipal();  <-- principal is
always null
- KeycloakSecurityContext session = (KeycloakSecurityContext)
request.getAttribute(KeycloakSecurityContext.class.getName()); <-- session
is always null
- sc.getCallerPrincipal().getName() <-- returns 'anonymous', so it seems it
isn't taking security-domain?
- request.isUserInRole("user") <-- returns null
- HttpResponse response = client.execute(get) <-- throws an exception:
org.jboss.resteasy.spi.UnauthorizedException: Bearer
- If I use @RolesAllowed({ "user" }) annotation I get this error: JBAS014502:
The invocation is not allowed in the method
- String token = request.getHeader("authorization"); <-- I get
'Authorization:Bearer eyJhbGciOiJSUzI1Ni...'

I suppose i'm doing it wrong, but I don't know what is the correct form.
Could I get user information from token received?

Thanks in advance,
Juan Escot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150120/135834bc/attachment.html 

From stian at redhat.com  Tue Jan 20 06:41:28 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 Jan 2015 06:41:28 -0500 (EST)
Subject: [keycloak-dev] Rest Service authentication.
In-Reply-To: <CALjk8zy0Sx=d_=aP9t5fm=KLrVE2rMQ+qmtDGTsQWFTT=Y8Lbw@mail.gmail.com>
References: <CALjk8zy0Sx=d_=aP9t5fm=KLrVE2rMQ+qmtDGTsQWFTT=Y8Lbw@mail.gmail.com>
Message-ID: <55930001.13710621.1421754088543.JavaMail.zimbra@redhat.com>

For the security context to propagate to EJBs you need to create a shared security domain, see http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/ch07.html#jboss-adapter-installation

----- Original Message -----
> From: "Juan Escot" <juan.escot at cdtec.es>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 January, 2015 11:46:36 AM
> Subject: [keycloak-dev] Rest Service authentication.
> 
> Hi,
> I'm developing an application with AngularJS and Rest Services. I'm using
> Keycloak for authentication and role management.
> 
> Mi Angular project is registered as 'confidential' and work's fine. It
> refresh tokens and sends it on header like this: 'Authorization:Bearer
> eyJhbGciOiJSUzI1Ni...'
> 
> Mi java project is defined as 'bearer only' and it's developed with Java EJBs
> as Rest Services. I need more control over permissions and roles, so I don't
> want to secure my project with security-contraints at web.xml. I'd like to
> get user info and roles inside my Rest methods from token received. I have
> checked I received the token with this line:
> 
> String token = request.getHeader("authorization");
> 
> But, I can't get any additional information about user. I have tried
> different approaches but I can't fin a solution. Could I have a Keycloak
> object with user info?.
> 
> This is a fragment of my code with all my attemps:
> 
> @Stateless
> @LocalBean
> @Path("/promociones")
> @SecurityDomain("keycloak")
> public class PromocionRest {
> @Context
> HttpServletRequest request;
> @Context
> SecurityContext securityContext;
> @Resource
> SessionContext sc;
> @GET
> @Produces("application/json")
> @Path("/list")
> //@RolesAllowed({ "user" }) <-- If I use this annotation y get an error.
> @PermitAll
> public RespuestaListaBase<Promocion> listadoPromociones(...){
> KeycloakPrincipal principal =
> (KeycloakPrincipal)securityContext.getUserPrincipal();
> KeycloakSecurityContext session = (KeycloakSecurityContext)
> request.getAttribute(KeycloakSecurityContext.class.getName());
> if (sc!=null && sc.getCallerPrincipal()!=null){
> System.out.println("Principal's name according to EJB: " +
> sc.getCallerPrincipal().getName());
> }
> 
> System.out.println("Is user in role 'user'? " +
> request.isUserInRole("user"));
> 
> String token = request.getHeader("authorization");
> HttpClient client = new HttpClientBuilder().disableTrustManager().build();
> try {
> String url = request.getRequestURL().toString();
> url = url.substring(0, url.indexOf('/', 8));
> HttpGet get = new HttpGet(url + "/auth/admin/realms/demo/roles");
> get.addHeader("Authorization", "Bearer " + token);
> try {
> HttpResponse response = client.execute(get);
> if (response.getStatusLine().getStatusCode() != 200) {
> //throw new Failure(response.getStatusLine().getStatusCode());
> }
> HttpEntity entity = response.getEntity();
> InputStream is = entity.getContent();
> 
> } catch (IOException e) {
> throw new RuntimeException(e);
> }
> } finally {
> client.getConnectionManager().shutdown();
> }
> }
> }
> 
> I also have configured jboss-web.xml like this:
> <jboss-web>
> <security-domain>keycloak</security-domain>
> </jboss-web>
> 
> And web.xml like this:
> <login-config>
> <auth-method>KEYCLOAK</auth-method>
> <realm-name>demo</realm-name>
> </login-config>
> 
> <security-role>
> <role-name>user</role-name>
> </security-role>
> 
> Some notes about the code:
> - KeycloakPrincipal principal =
> (KeycloakPrincipal)securityContext.getUserPrincipal(); <-- principal is
> always null
> - KeycloakSecurityContext session = (KeycloakSecurityContext)
> request.getAttribute(KeycloakSecurityContext.class.getName()); <-- session
> is always null
> - sc.getCallerPrincipal().getName() <-- returns 'anonymous', so it seems it
> isn't taking security-domain?
> - request.isUserInRole("user") <-- returns null
> - HttpResponse response = client.execute(get) <-- throws an exception:
> org.jboss.resteasy.spi.UnauthorizedException: Bearer
> - If I use @RolesAllowed({ "user" }) annotation I get this error: JBAS014502:
> The invocation is not allowed in the method
> - String token = request.getHeader("authorization"); <-- I get
> 'Authorization:Bearer eyJhbGciOiJSUzI1Ni...'
> 
> I suppose i'm doing it wrong, but I don't know what is the correct form.
> Could I get user information from token received?
> 
> Thanks in advance,
> Juan Escot
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From juan.escot at cdtec.es  Tue Jan 20 08:15:17 2015
From: juan.escot at cdtec.es (Juan Escot)
Date: Tue, 20 Jan 2015 14:15:17 +0100
Subject: [keycloak-dev] Rest Service authentication.
In-Reply-To: <55930001.13710621.1421754088543.JavaMail.zimbra@redhat.com>
References: <CALjk8zy0Sx=d_=aP9t5fm=KLrVE2rMQ+qmtDGTsQWFTT=Y8Lbw@mail.gmail.com>
	<55930001.13710621.1421754088543.JavaMail.zimbra@redhat.com>
Message-ID: <CALjk8zz0R0Hf6C++YGLb6vR88GVB7xQ-ot-Bp_rh81-5v=k53w@mail.gmail.com>

Yes, I already have created it. I'm using Jboss EAP 6.3. I have installed
the adapter. But I have found a difference between adapter installation in
Keycloak 1.0.4.Final and 1.1.0.beta2.

I'm using 1.0.4.Final and I add this line (as described at for Jboss EAP at
http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter-installation
):
<extension module="org.keycloak.keycloak-as7-subsystem"/>

In 1.1.0.beta2 this configuration seems to be only for AS7. Should I use
this? If I try it, I get an error (JBAS014674 module cannot be loaded)
<extension module="org.keycloak.keycloak-subsystem"/>

All changes made at my standalone.xml are:

<extensions>
<extension module="org.keycloak.keycloak-as7-subsystem"/>
...
</extensions>
...
<security-domains>
<security-domain name="keycloak">
<authentication>
<login-module code="org.keycloak.adapters.jboss.KeycloakLoginModule"
flag="required"/>
</authentication>
</security-domain>
...
</security-domains>

Do you think is a configuration problem? Do any of my attemps to get user
information should work? Which one?

Regards,
Juan Escot




2015-01-20 12:41 GMT+01:00 Stian Thorgersen <stian at redhat.com>:

> For the security context to propagate to EJBs you need to create a shared
> security domain, see
> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/ch07.html#jboss-adapter-installation
>
> ----- Original Message -----
> > From: "Juan Escot" <juan.escot at cdtec.es>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 20 January, 2015 11:46:36 AM
> > Subject: [keycloak-dev] Rest Service authentication.
> >
> > Hi,
> > I'm developing an application with AngularJS and Rest Services. I'm using
> > Keycloak for authentication and role management.
> >
> > Mi Angular project is registered as 'confidential' and work's fine. It
> > refresh tokens and sends it on header like this: 'Authorization:Bearer
> > eyJhbGciOiJSUzI1Ni...'
> >
> > Mi java project is defined as 'bearer only' and it's developed with Java
> EJBs
> > as Rest Services. I need more control over permissions and roles, so I
> don't
> > want to secure my project with security-contraints at web.xml. I'd like
> to
> > get user info and roles inside my Rest methods from token received. I
> have
> > checked I received the token with this line:
> >
> > String token = request.getHeader("authorization");
> >
> > But, I can't get any additional information about user. I have tried
> > different approaches but I can't fin a solution. Could I have a Keycloak
> > object with user info?.
> >
> > This is a fragment of my code with all my attemps:
> >
> > @Stateless
> > @LocalBean
> > @Path("/promociones")
> > @SecurityDomain("keycloak")
> > public class PromocionRest {
> > @Context
> > HttpServletRequest request;
> > @Context
> > SecurityContext securityContext;
> > @Resource
> > SessionContext sc;
> > @GET
> > @Produces("application/json")
> > @Path("/list")
> > //@RolesAllowed({ "user" }) <-- If I use this annotation y get an error.
> > @PermitAll
> > public RespuestaListaBase<Promocion> listadoPromociones(...){
> > KeycloakPrincipal principal =
> > (KeycloakPrincipal)securityContext.getUserPrincipal();
> > KeycloakSecurityContext session = (KeycloakSecurityContext)
> > request.getAttribute(KeycloakSecurityContext.class.getName());
> > if (sc!=null && sc.getCallerPrincipal()!=null){
> > System.out.println("Principal's name according to EJB: " +
> > sc.getCallerPrincipal().getName());
> > }
> >
> > System.out.println("Is user in role 'user'? " +
> > request.isUserInRole("user"));
> >
> > String token = request.getHeader("authorization");
> > HttpClient client = new
> HttpClientBuilder().disableTrustManager().build();
> > try {
> > String url = request.getRequestURL().toString();
> > url = url.substring(0, url.indexOf('/', 8));
> > HttpGet get = new HttpGet(url + "/auth/admin/realms/demo/roles");
> > get.addHeader("Authorization", "Bearer " + token);
> > try {
> > HttpResponse response = client.execute(get);
> > if (response.getStatusLine().getStatusCode() != 200) {
> > //throw new Failure(response.getStatusLine().getStatusCode());
> > }
> > HttpEntity entity = response.getEntity();
> > InputStream is = entity.getContent();
> >
> > } catch (IOException e) {
> > throw new RuntimeException(e);
> > }
> > } finally {
> > client.getConnectionManager().shutdown();
> > }
> > }
> > }
> >
> > I also have configured jboss-web.xml like this:
> > <jboss-web>
> > <security-domain>keycloak</security-domain>
> > </jboss-web>
> >
> > And web.xml like this:
> > <login-config>
> > <auth-method>KEYCLOAK</auth-method>
> > <realm-name>demo</realm-name>
> > </login-config>
> >
> > <security-role>
> > <role-name>user</role-name>
> > </security-role>
> >
> > Some notes about the code:
> > - KeycloakPrincipal principal =
> > (KeycloakPrincipal)securityContext.getUserPrincipal(); <-- principal is
> > always null
> > - KeycloakSecurityContext session = (KeycloakSecurityContext)
> > request.getAttribute(KeycloakSecurityContext.class.getName()); <--
> session
> > is always null
> > - sc.getCallerPrincipal().getName() <-- returns 'anonymous', so it seems
> it
> > isn't taking security-domain?
> > - request.isUserInRole("user") <-- returns null
> > - HttpResponse response = client.execute(get) <-- throws an exception:
> > org.jboss.resteasy.spi.UnauthorizedException: Bearer
> > - If I use @RolesAllowed({ "user" }) annotation I get this error:
> JBAS014502:
> > The invocation is not allowed in the method
> > - String token = request.getHeader("authorization"); <-- I get
> > 'Authorization:Bearer eyJhbGciOiJSUzI1Ni...'
> >
> > I suppose i'm doing it wrong, but I don't know what is the correct form.
> > Could I get user information from token received?
> >
> > Thanks in advance,
> > Juan Escot
> >
> > _______________________________________________
> > 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/20150120/d5e28ab8/attachment-0001.html 

From bburke at redhat.com  Tue Jan 20 09:13:44 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 Jan 2015 09:13:44 -0500
Subject: [keycloak-dev] Rest Service authentication.
In-Reply-To: <CALjk8zz0R0Hf6C++YGLb6vR88GVB7xQ-ot-Bp_rh81-5v=k53w@mail.gmail.com>
References: <CALjk8zy0Sx=d_=aP9t5fm=KLrVE2rMQ+qmtDGTsQWFTT=Y8Lbw@mail.gmail.com>	<55930001.13710621.1421754088543.JavaMail.zimbra@redhat.com>
	<CALjk8zz0R0Hf6C++YGLb6vR88GVB7xQ-ot-Bp_rh81-5v=k53w@mail.gmail.com>
Message-ID: <54BE6298.6070207@redhat.com>

You still need to set up servlet security though and all the security 
constraints.  Set up your security constraints to be very broad, i.e. 
"*", then use @RolesAllowed within your EJBs.

On 1/20/2015 8:15 AM, Juan Escot wrote:
> Yes, I already have created it. I'm using Jboss EAP 6.3. I have
> installed the adapter. But I have found a difference between adapter
> installation in Keycloak 1.0.4.Final and 1.1.0.beta2.
>
> I'm using 1.0.4.Final and I add this line (as described at for Jboss EAP
> at
> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter-installation
> ):
> <extension module="org.keycloak.keycloak-as7-subsystem"/>
>
> In 1.1.0.beta2 this configuration seems to be only for AS7. Should I use
> this? If I try it, I get an error (JBAS014674 module cannot be loaded)
> <extension module="org.keycloak.keycloak-subsystem"/>
>
> All changes made at my standalone.xml are:
>
> <extensions>
> <extension module="org.keycloak.keycloak-as7-subsystem"/>
> ...
> </extensions>
> ...
> <security-domains>
> <security-domain name="keycloak">
> <authentication>
> <login-module code="org.keycloak.adapters.jboss.KeycloakLoginModule"
> flag="required"/>
> </authentication>
> </security-domain>
> ...
> </security-domains>
>
> Do you think is a configuration problem? Do any of my attemps to get
> user information should work? Which one?
>
> Regards,
> Juan Escot
>
>
>
>
> 2015-01-20 12:41 GMT+01:00 Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>>:
>
>     For the security context to propagate to EJBs you need to create a
>     shared security domain, see
>     http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/ch07.html#jboss-adapter-installation
>
>     ----- Original Message -----
>      > From: "Juan Escot" <juan.escot at cdtec.es <mailto:juan.escot at cdtec.es>>
>      > To: keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>      > Sent: Tuesday, 20 January, 2015 11:46:36 AM
>      > Subject: [keycloak-dev] Rest Service authentication.
>      >
>      > Hi,
>      > I'm developing an application with AngularJS and Rest Services.
>     I'm using
>      > Keycloak for authentication and role management.
>      >
>      > Mi Angular project is registered as 'confidential' and work's
>     fine. It
>      > refresh tokens and sends it on header like this:
>     'Authorization:Bearer
>      > eyJhbGciOiJSUzI1Ni...'
>      >
>      > Mi java project is defined as 'bearer only' and it's developed
>     with Java EJBs
>      > as Rest Services. I need more control over permissions and roles,
>     so I don't
>      > want to secure my project with security-contraints at web.xml.
>     I'd like to
>      > get user info and roles inside my Rest methods from token
>     received. I have
>      > checked I received the token with this line:
>      >
>      > String token = request.getHeader("authorization");
>      >
>      > But, I can't get any additional information about user. I have tried
>      > different approaches but I can't fin a solution. Could I have a
>     Keycloak
>      > object with user info?.
>      >
>      > This is a fragment of my code with all my attemps:
>      >
>      > @Stateless
>      > @LocalBean
>      > @Path("/promociones")
>      > @SecurityDomain("keycloak")
>      > public class PromocionRest {
>      > @Context
>      > HttpServletRequest request;
>      > @Context
>      > SecurityContext securityContext;
>      > @Resource
>      > SessionContext sc;
>      > @GET
>      > @Produces("application/json")
>      > @Path("/list")
>      > //@RolesAllowed({ "user" }) <-- If I use this annotation y get an
>     error.
>      > @PermitAll
>      > public RespuestaListaBase<Promocion> listadoPromociones(...){
>      > KeycloakPrincipal principal =
>      > (KeycloakPrincipal)securityContext.getUserPrincipal();
>      > KeycloakSecurityContext session = (KeycloakSecurityContext)
>      > request.getAttribute(KeycloakSecurityContext.class.getName());
>      > if (sc!=null && sc.getCallerPrincipal()!=null){
>      > System.out.println("Principal's name according to EJB: " +
>      > sc.getCallerPrincipal().getName());
>      > }
>      >
>      > System.out.println("Is user in role 'user'? " +
>      > request.isUserInRole("user"));
>      >
>      > String token = request.getHeader("authorization");
>      > HttpClient client = new
>     HttpClientBuilder().disableTrustManager().build();
>      > try {
>      > String url = request.getRequestURL().toString();
>      > url = url.substring(0, url.indexOf('/', 8));
>      > HttpGet get = new HttpGet(url + "/auth/admin/realms/demo/roles");
>      > get.addHeader("Authorization", "Bearer " + token);
>      > try {
>      > HttpResponse response = client.execute(get);
>      > if (response.getStatusLine().getStatusCode() != 200) {
>      > //throw new Failure(response.getStatusLine().getStatusCode());
>      > }
>      > HttpEntity entity = response.getEntity();
>      > InputStream is = entity.getContent();
>      >
>      > } catch (IOException e) {
>      > throw new RuntimeException(e);
>      > }
>      > } finally {
>      > client.getConnectionManager().shutdown();
>      > }
>      > }
>      > }
>      >
>      > I also have configured jboss-web.xml like this:
>      > <jboss-web>
>      > <security-domain>keycloak</security-domain>
>      > </jboss-web>
>      >
>      > And web.xml like this:
>      > <login-config>
>      > <auth-method>KEYCLOAK</auth-method>
>      > <realm-name>demo</realm-name>
>      > </login-config>
>      >
>      > <security-role>
>      > <role-name>user</role-name>
>      > </security-role>
>      >
>      > Some notes about the code:
>      > - KeycloakPrincipal principal =
>      > (KeycloakPrincipal)securityContext.getUserPrincipal(); <--
>     principal is
>      > always null
>      > - KeycloakSecurityContext session = (KeycloakSecurityContext)
>      > request.getAttribute(KeycloakSecurityContext.class.getName());
>     <-- session
>      > is always null
>      > - sc.getCallerPrincipal().getName() <-- returns 'anonymous', so
>     it seems it
>      > isn't taking security-domain?
>      > - request.isUserInRole("user") <-- returns null
>      > - HttpResponse response = client.execute(get) <-- throws an
>     exception:
>      > org.jboss.resteasy.spi.UnauthorizedException: Bearer
>      > - If I use @RolesAllowed({ "user" }) annotation I get this error:
>     JBAS014502:
>      > The invocation is not allowed in the method
>      > - String token = request.getHeader("authorization"); <-- I get
>      > 'Authorization:Bearer eyJhbGciOiJSUzI1Ni...'
>      >
>      > I suppose i'm doing it wrong, but I don't know what is the
>     correct form.
>      > Could I get user information from token received?
>      >
>      > Thanks in advance,
>      > Juan Escot
>      >
>      > _______________________________________________
>      > 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

From gerbermichi at me.com  Tue Jan 20 09:37:14 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 20 Jan 2015 14:37:14 +0000 (GMT)
Subject: [keycloak-dev] Password reset is possible with expired link -
	KEYCLOAK-980
Message-ID: <3dce2c56-f953-4bbb-b44c-45cf64342a9f@me.com>

Hi,
can you fix this issue in 1.1.0 Final?
https://issues.jboss.org/browse/KEYCLOAK-980

Thank you
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150120/892ae127/attachment.html 

From stian at redhat.com  Tue Jan 20 09:41:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 Jan 2015 09:41:31 -0500 (EST)
Subject: [keycloak-dev] Password reset is possible with expired link
	-	KEYCLOAK-980
In-Reply-To: <3dce2c56-f953-4bbb-b44c-45cf64342a9f@me.com>
References: <3dce2c56-f953-4bbb-b44c-45cf64342a9f@me.com>
Message-ID: <1604414767.13864843.1421764891877.JavaMail.zimbra@redhat.com>

Absolutely, pretty nasty one!

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 January, 2015 3:37:14 PM
> Subject: [keycloak-dev] Password reset is possible with expired link -	KEYCLOAK-980
> 
> Hi,
> can you fix this issue in 1.1.0 Final?
> https://issues.jboss.org/browse/KEYCLOAK-980
> 
> Thank you
> Michael
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Tue Jan 20 10:54:33 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 Jan 2015 10:54:33 -0500 (EST)
Subject: [keycloak-dev] Provider modules
In-Reply-To: <792778315.13925697.1421768839245.JavaMail.zimbra@redhat.com>
Message-ID: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>

As I said to make sure we're all on the same page here's my view on what we've just discussed:

1. A user creates a module for the provider
2. The user copies the module into '/modules'
3. The user registers the module with the auth-server subsystem. This can be done either by directly editing standalone.xml or through CLI. Example snippet from standalone.xml would look like:

    <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
        <auth-server name="main-auth-server">
            <enabled>true</enabled>
            <web-context>auth</web-context>
            <providers>
                <module name="org.acme.userprovider" />
                <module name="org.acme.anotherprovider" />
            </providers>
        </auth-server>
    </subsystem>

4. When a new provider module is registered Keycloak would need to be reloaded

This will require some changes to how Keycloak loads/finds providers as it needs to not only look in its own ClassPath for providers, but also in all ModuleClassPath that is referenced in the subsystem.

From bburke at redhat.com  Tue Jan 20 11:15:55 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 Jan 2015 11:15:55 -0500
Subject: [keycloak-dev] Provider modules
In-Reply-To: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
Message-ID: <54BE7F3B.4010706@redhat.com>



On 1/20/2015 10:54 AM, Stian Thorgersen wrote:
> As I said to make sure we're all on the same page here's my view on what we've just discussed:
>
> 1. A user creates a module for the provider
> 2. The user copies the module into '/modules'
> 3. The user registers the module with the auth-server subsystem. This can be done either by directly editing standalone.xml or through CLI. Example snippet from standalone.xml would look like:
>
>      <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>          <auth-server name="main-auth-server">
>              <enabled>true</enabled>
>              <web-context>auth</web-context>
>              <providers>
>                  <module name="org.acme.userprovider" />
>                  <module name="org.acme.anotherprovider" />
>              </providers>
>          </auth-server>
>      </subsystem>
>
> 4. When a new provider module is registered Keycloak would need to be reloaded
>

Don't you have to restart the entire server if you add a new module?


This should work too, with no code changes, no funky classloading:

1. Move all keycloak archives to modules
2. add jboss-deployment-structure.xml to embedded WAR
3. add a "keycloak-providers" module that only contains a module.xml 
definition
4. User creates a module for the provider
5. User edits keycloak-providers module.xml file importing the user module
6. restart server.



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

From ssilvert at redhat.com  Tue Jan 20 11:38:22 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 20 Jan 2015 11:38:22 -0500 (EST)
Subject: [keycloak-dev] Provider modules
In-Reply-To: <54BE7F3B.4010706@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
	<54BE7F3B.4010706@redhat.com>
Message-ID: <628510497.16519377.1421771902172.JavaMail.zimbra@redhat.com>



----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Tuesday, January 20, 2015 11:15:55 AM
Subject: Re: [keycloak-dev] Provider modules



On 1/20/2015 10:54 AM, Stian Thorgersen wrote:
> As I said to make sure we're all on the same page here's my view on what we've just discussed:
>
> 1. A user creates a module for the provider
> 2. The user copies the module into '/modules'
> 3. The user registers the module with the auth-server subsystem. This can be done either by directly editing standalone.xml or through CLI. Example snippet from standalone.xml would look like:
>
>      <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>          <auth-server name="main-auth-server">
>              <enabled>true</enabled>
>              <web-context>auth</web-context>
>              <providers>
>                  <module name="org.acme.userprovider" />
>                  <module name="org.acme.anotherprovider" />
>              </providers>
>          </auth-server>
>      </subsystem>
>
> 4. When a new provider module is registered Keycloak would need to be reloaded
>

>Don't you have to restart the entire server if you add a new module?

I'm 99% sure that you don't have to restart the whole server.  Just redeploying the WAR should do the trick.


>This should work too, with no code changes, no funky classloading:

>1. Move all keycloak archives to modules
>2. add jboss-deployment-structure.xml to embedded WAR
>3. add a "keycloak-providers" module that only contains a module.xml 
>definition
>4. User creates a module for the provider
>5. User edits keycloak-providers module.xml file importing the user module
>6. restart server.

Yes, that will work too.  But long term, I think we should do what Stian is talking about.  The EJB subsystem does the same thing.  It allows you to add global modules in standalone.xml.

Also, if we want to support two kc servers in the same domain with different configs, we can't let them edit jboss-deployment-structure.xml.



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

From gerbermichi at me.com  Tue Jan 20 11:42:49 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 20 Jan 2015 16:42:49 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_Re=3A__Password_reset_is_possible_with_?=
 =?utf-8?q?expired_link_-=09KEYCLOAK-980?=
Message-ID: <0e74da71-caa1-4ce4-bf5f-2fc0a73ed45f@me.com>

Thank you!

I found another bug which is very critical. This one allows users to login as any user, even as an administrator with all privileges...
https://issues.jboss.org/browse/KEYCLOAK-983

Am 20. Januar 2015 um 15:41 schrieb Stian Thorgersen <stian at redhat.com>:

Absolutely, pretty nasty one!

----- Original Message -----
From: "Michael Gerber" <gerbermichi at me.com>
To: keycloak-dev at lists.jboss.org
Sent: Tuesday, 20 January, 2015 3:37:14 PM
Subject: [keycloak-dev] Password reset is possible with expired link - ? ? ?KEYCLOAK-980
Hi,
can you fix this issue in 1.1.0 Final?
https://issues.jboss.org/browse/KEYCLOAK-980
Thank you
Michael
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150120/e27b9214/attachment-0001.html 

From stian at redhat.com  Tue Jan 20 12:03:59 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 Jan 2015 12:03:59 -0500 (EST)
Subject: [keycloak-dev] Provider modules
In-Reply-To: <54BE7F3B.4010706@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
	<54BE7F3B.4010706@redhat.com>
Message-ID: <1436131492.13978209.1421773439250.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 January, 2015 5:15:55 PM
> Subject: Re: [keycloak-dev] Provider modules
> 
> 
> 
> On 1/20/2015 10:54 AM, Stian Thorgersen wrote:
> > As I said to make sure we're all on the same page here's my view on what
> > we've just discussed:
> >
> > 1. A user creates a module for the provider
> > 2. The user copies the module into '/modules'
> > 3. The user registers the module with the auth-server subsystem. This can
> > be done either by directly editing standalone.xml or through CLI. Example
> > snippet from standalone.xml would look like:
> >
> >      <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
> >          <auth-server name="main-auth-server">
> >              <enabled>true</enabled>
> >              <web-context>auth</web-context>
> >              <providers>
> >                  <module name="org.acme.userprovider" />
> >                  <module name="org.acme.anotherprovider" />
> >              </providers>
> >          </auth-server>
> >      </subsystem>
> >
> > 4. When a new provider module is registered Keycloak would need to be
> > reloaded
> >
> 
> Don't you have to restart the entire server if you add a new module?
> 
> 
> This should work too, with no code changes, no funky classloading:
> 
> 1. Move all keycloak archives to modules
> 2. add jboss-deployment-structure.xml to embedded WAR
> 3. add a "keycloak-providers" module that only contains a module.xml
> definition
> 4. User creates a module for the provider
> 5. User edits keycloak-providers module.xml file importing the user module
> 6. restart server.

Why would you need jboss-deployment-structure.xml to embedded WAR?

The problem with that approach is that all providers are loaded from the same class-loader so there would be issues if providers use different versions of the same library. I also think it would be more natural for a WildFly user to edit standalone.xml or use the CLI than to add dependencies to an existing module. Finally another issue happens when someone upgrades/patches Keycloak, would they not then override the keycloak-providers module.xml and have to add everything again?

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

From stian at redhat.com  Tue Jan 20 12:04:30 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 20 Jan 2015 12:04:30 -0500 (EST)
Subject: [keycloak-dev] Password reset is possible with expired link
	-	KEYCLOAK-980
In-Reply-To: <0e74da71-caa1-4ce4-bf5f-2fc0a73ed45f@me.com>
References: <0e74da71-caa1-4ce4-bf5f-2fc0a73ed45f@me.com>
Message-ID: <710430013.13978511.1421773470728.JavaMail.zimbra@redhat.com>

That's bad - I'll fix both of these asap

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 January, 2015 5:42:49 PM
> Subject: Re: [keycloak-dev] Password reset is possible with expired link -	KEYCLOAK-980
> 
> Thank you!
> 
> I found another bug which is very critical. This one allows users to login as
> any user, even as an administrator with all privileges...
> https://issues.jboss.org/browse/KEYCLOAK-983
> 
> Am 20. Januar 2015 um 15:41 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> Absolutely, pretty nasty one!
> 
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 January, 2015 3:37:14 PM
> Subject: [keycloak-dev] Password reset is possible with expired link -
> ? ? ?KEYCLOAK-980
> Hi,
> can you fix this issue in 1.1.0 Final?
> https://issues.jboss.org/browse/KEYCLOAK-980
> Thank you
> Michael
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ssilvert at redhat.com  Tue Jan 20 12:17:55 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 20 Jan 2015 12:17:55 -0500 (EST)
Subject: [keycloak-dev] Provider modules
In-Reply-To: <628510497.16519377.1421771902172.JavaMail.zimbra@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
	<54BE7F3B.4010706@redhat.com>
	<628510497.16519377.1421771902172.JavaMail.zimbra@redhat.com>
Message-ID: <110802468.16554087.1421774275239.JavaMail.zimbra@redhat.com>



----- Original Message -----
From: "Stan Silvert" <ssilvert at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Tuesday, January 20, 2015 11:38:22 AM
Subject: Re: [keycloak-dev] Provider modules



> Also, if we want to support two kc servers in the same domain with different configs, we can't let them edit jboss-deployment-structure.xml.

This may bear further explanation.  With the subsystem, we allow you to define as many keycloak servers as you want.  These run completely independently.  As far as the domain is concerned, they are two completely different deployments and you can provision them to run on whatever servers each is assigned to.  But if you change something inside the WAR, it will affect every keycloak server you define.

From ssilvert at redhat.com  Tue Jan 20 12:24:09 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 20 Jan 2015 12:24:09 -0500 (EST)
Subject: [keycloak-dev] Provider modules
In-Reply-To: <1436131492.13978209.1421773439250.JavaMail.zimbra@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
	<54BE7F3B.4010706@redhat.com>
	<1436131492.13978209.1421773439250.JavaMail.zimbra@redhat.com>
Message-ID: <514445128.16556759.1421774649722.JavaMail.zimbra@redhat.com>



----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Tuesday, January 20, 2015 12:03:59 PM
Subject: Re: [keycloak-dev] Provider modules


> Why would you need jboss-deployment-structure.xml to embedded WAR?

> The problem with that approach is that all providers are loaded from the same class-loader so there would be issues if providers use different versions of the same library. I also think it would be more natural for a WildFly user to edit standalone.xml or use the CLI than to add dependencies to an existing module. Finally another issue happens when someone upgrades/patches Keycloak, would they not then override the keycloak-providers module.xml and have to add everything again?

Yes they would.  That's another reason why, in general, hacking the WAR (or anything else we ship) is a bad idea. 

Plus, it drives the support guys absolutely nuts!

From bburke at redhat.com  Tue Jan 20 12:42:33 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 Jan 2015 12:42:33 -0500
Subject: [keycloak-dev] Provider modules
In-Reply-To: <514445128.16556759.1421774649722.JavaMail.zimbra@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
	<54BE7F3B.4010706@redhat.com>
	<1436131492.13978209.1421773439250.JavaMail.zimbra@redhat.com>
	<514445128.16556759.1421774649722.JavaMail.zimbra@redhat.com>
Message-ID: <54BE9389.9030104@redhat.com>

I'm just saying that editing a module.xml file requires no code changes 
and we can ship 1.1.

Bill


On 1/20/2015 12:24 PM, Stan Silvert wrote:
>
>
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 20, 2015 12:03:59 PM
> Subject: Re: [keycloak-dev] Provider modules
>
>
>> Why would you need jboss-deployment-structure.xml to embedded WAR?
>
>> The problem with that approach is that all providers are loaded from the same class-loader so there would be issues if providers use different versions of the same library. I also think it would be more natural for a WildFly user to edit standalone.xml or use the CLI than to add dependencies to an existing module. Finally another issue happens when someone upgrades/patches Keycloak, would they not then override the keycloak-providers module.xml and have to add everything again?
>
> Yes they would.  That's another reason why, in general, hacking the WAR (or anything else we ship) is a bad idea.
>
> Plus, it drives the support guys absolutely nuts!
>

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

From bburke at redhat.com  Tue Jan 20 16:35:52 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 20 Jan 2015 16:35:52 -0500
Subject: [keycloak-dev] Provider modules
In-Reply-To: <54BE9389.9030104@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>	<54BE7F3B.4010706@redhat.com>	<1436131492.13978209.1421773439250.JavaMail.zimbra@redhat.com>	<514445128.16556759.1421774649722.JavaMail.zimbra@redhat.com>
	<54BE9389.9030104@redhat.com>
Message-ID: <54BECA38.7020801@redhat.com>

Yo, still working on separation into modules, but...

Right now, we deploy our JPA plugins via the container deployer as part 
of the WAR.  Not sure if that the deployer will pick up these JPA 
plugins if they are in an imported module.

On 1/20/2015 12:42 PM, Bill Burke wrote:
> I'm just saying that editing a module.xml file requires no code changes
> and we can ship 1.1.
>
> Bill
>
>
> On 1/20/2015 12:24 PM, Stan Silvert wrote:
>>
>>
>> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, January 20, 2015 12:03:59 PM
>> Subject: Re: [keycloak-dev] Provider modules
>>
>>
>>> Why would you need jboss-deployment-structure.xml to embedded WAR?
>>
>>> The problem with that approach is that all providers are loaded from the same class-loader so there would be issues if providers use different versions of the same library. I also think it would be more natural for a WildFly user to edit standalone.xml or use the CLI than to add dependencies to an existing module. Finally another issue happens when someone upgrades/patches Keycloak, would they not then override the keycloak-providers module.xml and have to add everything again?
>>
>> Yes they would.  That's another reason why, in general, hacking the WAR (or anything else we ship) is a bad idea.
>>
>> Plus, it drives the support guys absolutely nuts!
>>
>

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

From stian at redhat.com  Wed Jan 21 01:15:48 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 21 Jan 2015 01:15:48 -0500 (EST)
Subject: [keycloak-dev] Provider modules
In-Reply-To: <54BECA38.7020801@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
	<54BE7F3B.4010706@redhat.com>
	<1436131492.13978209.1421773439250.JavaMail.zimbra@redhat.com>
	<514445128.16556759.1421774649722.JavaMail.zimbra@redhat.com>
	<54BE9389.9030104@redhat.com> <54BECA38.7020801@redhat.com>
Message-ID: <2105510642.14280248.1421820948326.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 20 January, 2015 10:35:52 PM
> Subject: Re: [keycloak-dev] Provider modules
> 
> Yo, still working on separation into modules, but...
> 
> Right now, we deploy our JPA plugins via the container deployer as part
> of the WAR.  Not sure if that the deployer will pick up these JPA
> plugins if they are in an imported module.

What's a JPA plugin? We manage everything JPA ourselves so what does it have to do with the deployer?

> 
> On 1/20/2015 12:42 PM, Bill Burke wrote:
> > I'm just saying that editing a module.xml file requires no code changes
> > and we can ship 1.1.
> >
> > Bill
> >
> >
> > On 1/20/2015 12:24 PM, Stan Silvert wrote:
> >>
> >>
> >> ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, January 20, 2015 12:03:59 PM
> >> Subject: Re: [keycloak-dev] Provider modules
> >>
> >>
> >>> Why would you need jboss-deployment-structure.xml to embedded WAR?
> >>
> >>> The problem with that approach is that all providers are loaded from the
> >>> same class-loader so there would be issues if providers use different
> >>> versions of the same library. I also think it would be more natural for
> >>> a WildFly user to edit standalone.xml or use the CLI than to add
> >>> dependencies to an existing module. Finally another issue happens when
> >>> someone upgrades/patches Keycloak, would they not then override the
> >>> keycloak-providers module.xml and have to add everything again?
> >>
> >> Yes they would.  That's another reason why, in general, hacking the WAR
> >> (or anything else we ship) is a bad idea.
> >>
> >> Plus, it drives the support guys absolutely nuts!
> >>
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From gerbermichi at me.com  Wed Jan 21 02:34:43 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Wed, 21 Jan 2015 07:34:43 +0000 (GMT)
Subject: [keycloak-dev] reset password leads to no state cookie
Message-ID: <b32faa27-e5f6-4107-b4a2-9db41a44f85a@me.com>

Hi

I use the wildfly adapter and receive a "No state cookie" error message if I open the reset password link in another browser.
It's totally clear why I receive this message, because my cookie does not exist anymore. But that looks a bit strange for a user.?

Is there a workaround to fix this issue?

Best
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150121/db5ecbe5/attachment.html 

From bburke at redhat.com  Wed Jan 21 09:44:49 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 21 Jan 2015 09:44:49 -0500
Subject: [keycloak-dev] Provider modules
In-Reply-To: <2105510642.14280248.1421820948326.JavaMail.zimbra@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
	<54BE7F3B.4010706@redhat.com>
	<1436131492.13978209.1421773439250.JavaMail.zimbra@redhat.com>
	<514445128.16556759.1421774649722.JavaMail.zimbra@redhat.com>
	<54BE9389.9030104@redhat.com> <54BECA38.7020801@redhat.com>
	<2105510642.14280248.1421820948326.JavaMail.zimbra@redhat.com>
Message-ID: <54BFBB61.30104@redhat.com>

Ah cool!  We do!  Sorry, I thought JPA was deployed by deployer.

On 1/21/2015 1:15 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 20 January, 2015 10:35:52 PM
>> Subject: Re: [keycloak-dev] Provider modules
>>
>> Yo, still working on separation into modules, but...
>>
>> Right now, we deploy our JPA plugins via the container deployer as part
>> of the WAR.  Not sure if that the deployer will pick up these JPA
>> plugins if they are in an imported module.
>
> What's a JPA plugin? We manage everything JPA ourselves so what does it have to do with the deployer?
>
>>
>> On 1/20/2015 12:42 PM, Bill Burke wrote:
>>> I'm just saying that editing a module.xml file requires no code changes
>>> and we can ship 1.1.
>>>
>>> Bill
>>>
>>>
>>> On 1/20/2015 12:24 PM, Stan Silvert wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Bill Burke" <bburke at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, January 20, 2015 12:03:59 PM
>>>> Subject: Re: [keycloak-dev] Provider modules
>>>>
>>>>
>>>>> Why would you need jboss-deployment-structure.xml to embedded WAR?
>>>>
>>>>> The problem with that approach is that all providers are loaded from the
>>>>> same class-loader so there would be issues if providers use different
>>>>> versions of the same library. I also think it would be more natural for
>>>>> a WildFly user to edit standalone.xml or use the CLI than to add
>>>>> dependencies to an existing module. Finally another issue happens when
>>>>> someone upgrades/patches Keycloak, would they not then override the
>>>>> keycloak-providers module.xml and have to add everything again?
>>>>
>>>> Yes they would.  That's another reason why, in general, hacking the WAR
>>>> (or anything else we ship) is a bad idea.
>>>>
>>>> Plus, it drives the support guys absolutely nuts!
>>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Wed Jan 21 09:48:27 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 21 Jan 2015 09:48:27 -0500 (EST)
Subject: [keycloak-dev] Provider modules
In-Reply-To: <54BFBB61.30104@redhat.com>
References: <2084010994.13932164.1421769273083.JavaMail.zimbra@redhat.com>
	<54BE7F3B.4010706@redhat.com>
	<1436131492.13978209.1421773439250.JavaMail.zimbra@redhat.com>
	<514445128.16556759.1421774649722.JavaMail.zimbra@redhat.com>
	<54BE9389.9030104@redhat.com> <54BECA38.7020801@redhat.com>
	<2105510642.14280248.1421820948326.JavaMail.zimbra@redhat.com>
	<54BFBB61.30104@redhat.com>
Message-ID: <32165439.14496472.1421851707579.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 21 January, 2015 3:44:49 PM
> Subject: Re: [keycloak-dev] Provider modules
> 
> Ah cool!  We do!  Sorry, I thought JPA was deployed by deployer.

Nope - in fact we've got work-arounds to prevent the deployer to meddle with our stuff ;)

The less the deployment processors do for us the better as we want to be in control! For example CDI and web services sub-subsystems are both bothering us from time to time, even though we use neither.

> 
> On 1/21/2015 1:15 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 20 January, 2015 10:35:52 PM
> >> Subject: Re: [keycloak-dev] Provider modules
> >>
> >> Yo, still working on separation into modules, but...
> >>
> >> Right now, we deploy our JPA plugins via the container deployer as part
> >> of the WAR.  Not sure if that the deployer will pick up these JPA
> >> plugins if they are in an imported module.
> >
> > What's a JPA plugin? We manage everything JPA ourselves so what does it
> > have to do with the deployer?
> >
> >>
> >> On 1/20/2015 12:42 PM, Bill Burke wrote:
> >>> I'm just saying that editing a module.xml file requires no code changes
> >>> and we can ship 1.1.
> >>>
> >>> Bill
> >>>
> >>>
> >>> On 1/20/2015 12:24 PM, Stan Silvert wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "Bill Burke" <bburke at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, January 20, 2015 12:03:59 PM
> >>>> Subject: Re: [keycloak-dev] Provider modules
> >>>>
> >>>>
> >>>>> Why would you need jboss-deployment-structure.xml to embedded WAR?
> >>>>
> >>>>> The problem with that approach is that all providers are loaded from
> >>>>> the
> >>>>> same class-loader so there would be issues if providers use different
> >>>>> versions of the same library. I also think it would be more natural for
> >>>>> a WildFly user to edit standalone.xml or use the CLI than to add
> >>>>> dependencies to an existing module. Finally another issue happens when
> >>>>> someone upgrades/patches Keycloak, would they not then override the
> >>>>> keycloak-providers module.xml and have to add everything again?
> >>>>
> >>>> Yes they would.  That's another reason why, in general, hacking the WAR
> >>>> (or anything else we ship) is a bad idea.
> >>>>
> >>>> Plus, it drives the support guys absolutely nuts!
> >>>>
> >>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From juan.escot at cdtec.es  Thu Jan 22 07:39:56 2015
From: juan.escot at cdtec.es (Juan Escot)
Date: Thu, 22 Jan 2015 13:39:56 +0100
Subject: [keycloak-dev] Rest Service authentication.
In-Reply-To: <54BE6298.6070207@redhat.com>
References: <CALjk8zy0Sx=d_=aP9t5fm=KLrVE2rMQ+qmtDGTsQWFTT=Y8Lbw@mail.gmail.com>
	<55930001.13710621.1421754088543.JavaMail.zimbra@redhat.com>
	<CALjk8zz0R0Hf6C++YGLb6vR88GVB7xQ-ot-Bp_rh81-5v=k53w@mail.gmail.com>
	<54BE6298.6070207@redhat.com>
Message-ID: <CALjk8zzBQWhkXoW75B+2XVnLWjoK868K2gZR16-=y6xuAx2NYg@mail.gmail.com>

Thanks for your answer. Once I have configured correctly the servlet, I can
use @RolesAllowed on my EJBs. KeycloakPrincipal and KeycloakSecurityContext
are now filled.

But now, I have a new issue. When users haven't permissions, jboss server
is returning 500 (Internal Server Error) error code. Exact error is this:
javax.ejb.ejbaccessexception: jbas014502: invocation on method: public xxxx
is not allowed.

I think it should return 403 (Forbidden) or 401 (Unauthorized), isn't it?
Is this behavior correct? Is it a JBoss or Keycloak issue?  Is it possible
to configure status code returned?


2015-01-20 15:13 GMT+01:00 Bill Burke <bburke at redhat.com>:

> You still need to set up servlet security though and all the security
> constraints.  Set up your security constraints to be very broad, i.e.
> "*", then use @RolesAllowed within your EJBs.
>
> On 1/20/2015 8:15 AM, Juan Escot wrote:
> > Yes, I already have created it. I'm using Jboss EAP 6.3. I have
> > installed the adapter. But I have found a difference between adapter
> > installation in Keycloak 1.0.4.Final and 1.1.0.beta2.
> >
> > I'm using 1.0.4.Final and I add this line (as described at for Jboss EAP
> > at
> >
> http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter-installation
> > ):
> > <extension module="org.keycloak.keycloak-as7-subsystem"/>
> >
> > In 1.1.0.beta2 this configuration seems to be only for AS7. Should I use
> > this? If I try it, I get an error (JBAS014674 module cannot be loaded)
> > <extension module="org.keycloak.keycloak-subsystem"/>
> >
> > All changes made at my standalone.xml are:
> >
> > <extensions>
> > <extension module="org.keycloak.keycloak-as7-subsystem"/>
> > ...
> > </extensions>
> > ...
> > <security-domains>
> > <security-domain name="keycloak">
> > <authentication>
> > <login-module code="org.keycloak.adapters.jboss.KeycloakLoginModule"
> > flag="required"/>
> > </authentication>
> > </security-domain>
> > ...
> > </security-domains>
> >
> > Do you think is a configuration problem? Do any of my attemps to get
> > user information should work? Which one?
> >
> > Regards,
> > Juan Escot
> >
> >
> >
> >
> > 2015-01-20 12:41 GMT+01:00 Stian Thorgersen <stian at redhat.com
> > <mailto:stian at redhat.com>>:
> >
> >     For the security context to propagate to EJBs you need to create a
> >     shared security domain, see
> >
> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/ch07.html#jboss-adapter-installation
> >
> >     ----- Original Message -----
> >      > From: "Juan Escot" <juan.escot at cdtec.es <mailto:
> juan.escot at cdtec.es>>
> >      > To: keycloak-dev at lists.jboss.org
> >     <mailto:keycloak-dev at lists.jboss.org>
> >      > Sent: Tuesday, 20 January, 2015 11:46:36 AM
> >      > Subject: [keycloak-dev] Rest Service authentication.
> >      >
> >      > Hi,
> >      > I'm developing an application with AngularJS and Rest Services.
> >     I'm using
> >      > Keycloak for authentication and role management.
> >      >
> >      > Mi Angular project is registered as 'confidential' and work's
> >     fine. It
> >      > refresh tokens and sends it on header like this:
> >     'Authorization:Bearer
> >      > eyJhbGciOiJSUzI1Ni...'
> >      >
> >      > Mi java project is defined as 'bearer only' and it's developed
> >     with Java EJBs
> >      > as Rest Services. I need more control over permissions and roles,
> >     so I don't
> >      > want to secure my project with security-contraints at web.xml.
> >     I'd like to
> >      > get user info and roles inside my Rest methods from token
> >     received. I have
> >      > checked I received the token with this line:
> >      >
> >      > String token = request.getHeader("authorization");
> >      >
> >      > But, I can't get any additional information about user. I have
> tried
> >      > different approaches but I can't fin a solution. Could I have a
> >     Keycloak
> >      > object with user info?.
> >      >
> >      > This is a fragment of my code with all my attemps:
> >      >
> >      > @Stateless
> >      > @LocalBean
> >      > @Path("/promociones")
> >      > @SecurityDomain("keycloak")
> >      > public class PromocionRest {
> >      > @Context
> >      > HttpServletRequest request;
> >      > @Context
> >      > SecurityContext securityContext;
> >      > @Resource
> >      > SessionContext sc;
> >      > @GET
> >      > @Produces("application/json")
> >      > @Path("/list")
> >      > //@RolesAllowed({ "user" }) <-- If I use this annotation y get an
> >     error.
> >      > @PermitAll
> >      > public RespuestaListaBase<Promocion> listadoPromociones(...){
> >      > KeycloakPrincipal principal =
> >      > (KeycloakPrincipal)securityContext.getUserPrincipal();
> >      > KeycloakSecurityContext session = (KeycloakSecurityContext)
> >      > request.getAttribute(KeycloakSecurityContext.class.getName());
> >      > if (sc!=null && sc.getCallerPrincipal()!=null){
> >      > System.out.println("Principal's name according to EJB: " +
> >      > sc.getCallerPrincipal().getName());
> >      > }
> >      >
> >      > System.out.println("Is user in role 'user'? " +
> >      > request.isUserInRole("user"));
> >      >
> >      > String token = request.getHeader("authorization");
> >      > HttpClient client = new
> >     HttpClientBuilder().disableTrustManager().build();
> >      > try {
> >      > String url = request.getRequestURL().toString();
> >      > url = url.substring(0, url.indexOf('/', 8));
> >      > HttpGet get = new HttpGet(url + "/auth/admin/realms/demo/roles");
> >      > get.addHeader("Authorization", "Bearer " + token);
> >      > try {
> >      > HttpResponse response = client.execute(get);
> >      > if (response.getStatusLine().getStatusCode() != 200) {
> >      > //throw new Failure(response.getStatusLine().getStatusCode());
> >      > }
> >      > HttpEntity entity = response.getEntity();
> >      > InputStream is = entity.getContent();
> >      >
> >      > } catch (IOException e) {
> >      > throw new RuntimeException(e);
> >      > }
> >      > } finally {
> >      > client.getConnectionManager().shutdown();
> >      > }
> >      > }
> >      > }
> >      >
> >      > I also have configured jboss-web.xml like this:
> >      > <jboss-web>
> >      > <security-domain>keycloak</security-domain>
> >      > </jboss-web>
> >      >
> >      > And web.xml like this:
> >      > <login-config>
> >      > <auth-method>KEYCLOAK</auth-method>
> >      > <realm-name>demo</realm-name>
> >      > </login-config>
> >      >
> >      > <security-role>
> >      > <role-name>user</role-name>
> >      > </security-role>
> >      >
> >      > Some notes about the code:
> >      > - KeycloakPrincipal principal =
> >      > (KeycloakPrincipal)securityContext.getUserPrincipal(); <--
> >     principal is
> >      > always null
> >      > - KeycloakSecurityContext session = (KeycloakSecurityContext)
> >      > request.getAttribute(KeycloakSecurityContext.class.getName());
> >     <-- session
> >      > is always null
> >      > - sc.getCallerPrincipal().getName() <-- returns 'anonymous', so
> >     it seems it
> >      > isn't taking security-domain?
> >      > - request.isUserInRole("user") <-- returns null
> >      > - HttpResponse response = client.execute(get) <-- throws an
> >     exception:
> >      > org.jboss.resteasy.spi.UnauthorizedException: Bearer
> >      > - If I use @RolesAllowed({ "user" }) annotation I get this error:
> >     JBAS014502:
> >      > The invocation is not allowed in the method
> >      > - String token = request.getHeader("authorization"); <-- I get
> >      > 'Authorization:Bearer eyJhbGciOiJSUzI1Ni...'
> >      >
> >      > I suppose i'm doing it wrong, but I don't know what is the
> >     correct form.
> >      > Could I get user information from token received?
> >      >
> >      > Thanks in advance,
> >      > Juan Escot
> >      >
> >      > _______________________________________________
> >      > 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
> _______________________________________________
> 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/20150122/4360fced/attachment-0001.html 

From bburke at redhat.com  Thu Jan 22 08:56:26 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 22 Jan 2015 08:56:26 -0500
Subject: [keycloak-dev] Rest Service authentication.
In-Reply-To: <CALjk8zzBQWhkXoW75B+2XVnLWjoK868K2gZR16-=y6xuAx2NYg@mail.gmail.com>
References: <CALjk8zy0Sx=d_=aP9t5fm=KLrVE2rMQ+qmtDGTsQWFTT=Y8Lbw@mail.gmail.com>	<55930001.13710621.1421754088543.JavaMail.zimbra@redhat.com>	<CALjk8zz0R0Hf6C++YGLb6vR88GVB7xQ-ot-Bp_rh81-5v=k53w@mail.gmail.com>	<54BE6298.6070207@redhat.com>
	<CALjk8zzBQWhkXoW75B+2XVnLWjoK868K2gZR16-=y6xuAx2NYg@mail.gmail.com>
Message-ID: <54C1018A.5030605@redhat.com>

Now you have to write an exception mapper for EJBException :)  EJB layer 
is throwing exception, JAX-RS sees an unkown exception, so it sends off 
a 500.

On 1/22/2015 7:39 AM, Juan Escot wrote:
> Thanks for your answer. Once I have configured correctly the servlet, I
> can use @RolesAllowed on my EJBs. KeycloakPrincipal
> and KeycloakSecurityContext are now filled.
>
> But now, I have a new issue. When users haven't permissions, jboss
> server is returning 500 (Internal Server Error) error code. Exact error
> is this:
> javax.ejb.ejbaccessexception: jbas014502: invocation on method: public
> xxxx is not allowed.
>
> I think it should return 403 (Forbidden) or 401 (Unauthorized), isn't
> it? Is this behavior correct? Is it a JBoss or Keycloak issue?  Is it
> possible to configure status code returned?
>
>
> 2015-01-20 15:13 GMT+01:00 Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>>:
>
>     You still need to set up servlet security though and all the security
>     constraints.  Set up your security constraints to be very broad, i.e.
>     "*", then use @RolesAllowed within your EJBs.
>
>     On 1/20/2015 8:15 AM, Juan Escot wrote:
>      > Yes, I already have created it. I'm using Jboss EAP 6.3. I have
>      > installed the adapter. But I have found a difference between adapter
>      > installation in Keycloak 1.0.4.Final and 1.1.0.beta2.
>      >
>      > I'm using 1.0.4.Final and I add this line (as described at for
>     Jboss EAP
>      > at
>      >
>     http://docs.jboss.org/keycloak/docs/1.0.4.Final/userguide/html/ch07.html#jboss-adapter-installation
>      > ):
>      > <extension module="org.keycloak.keycloak-as7-subsystem"/>
>      >
>      > In 1.1.0.beta2 this configuration seems to be only for AS7.
>     Should I use
>      > this? If I try it, I get an error (JBAS014674 module cannot be
>     loaded)
>      > <extension module="org.keycloak.keycloak-subsystem"/>
>      >
>      > All changes made at my standalone.xml are:
>      >
>      > <extensions>
>      > <extension module="org.keycloak.keycloak-as7-subsystem"/>
>      > ...
>      > </extensions>
>      > ...
>      > <security-domains>
>      > <security-domain name="keycloak">
>      > <authentication>
>      > <login-module code="org.keycloak.adapters.jboss.KeycloakLoginModule"
>      > flag="required"/>
>      > </authentication>
>      > </security-domain>
>      > ...
>      > </security-domains>
>      >
>      > Do you think is a configuration problem? Do any of my attemps to get
>      > user information should work? Which one?
>      >
>      > Regards,
>      > Juan Escot
>      >
>      >
>      >
>      >
>      > 2015-01-20 12:41 GMT+01:00 Stian Thorgersen <stian at redhat.com
>     <mailto:stian at redhat.com>
>      > <mailto:stian at redhat.com <mailto:stian at redhat.com>>>:
>      >
>      >     For the security context to propagate to EJBs you need to
>     create a
>      >     shared security domain, see
>      >
>     http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/ch07.html#jboss-adapter-installation
>      >
>      >     ----- Original Message -----
>      >      > From: "Juan Escot" <juan.escot at cdtec.es
>     <mailto:juan.escot at cdtec.es> <mailto:juan.escot at cdtec.es
>     <mailto:juan.escot at cdtec.es>>>
>      >      > To: 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>>
>      >      > Sent: Tuesday, 20 January, 2015 11:46:36 AM
>      >      > Subject: [keycloak-dev] Rest Service authentication.
>      >      >
>      >      > Hi,
>      >      > I'm developing an application with AngularJS and Rest
>     Services.
>      >     I'm using
>      >      > Keycloak for authentication and role management.
>      >      >
>      >      > Mi Angular project is registered as 'confidential' and work's
>      >     fine. It
>      >      > refresh tokens and sends it on header like this:
>      >     'Authorization:Bearer
>      >      > eyJhbGciOiJSUzI1Ni...'
>      >      >
>      >      > Mi java project is defined as 'bearer only' and it's developed
>      >     with Java EJBs
>      >      > as Rest Services. I need more control over permissions and
>     roles,
>      >     so I don't
>      >      > want to secure my project with security-contraints at web.xml.
>      >     I'd like to
>      >      > get user info and roles inside my Rest methods from token
>      >     received. I have
>      >      > checked I received the token with this line:
>      >      >
>      >      > String token = request.getHeader("authorization");
>      >      >
>      >      > But, I can't get any additional information about user. I
>     have tried
>      >      > different approaches but I can't fin a solution. Could I
>     have a
>      >     Keycloak
>      >      > object with user info?.
>      >      >
>      >      > This is a fragment of my code with all my attemps:
>      >      >
>      >      > @Stateless
>      >      > @LocalBean
>      >      > @Path("/promociones")
>      >      > @SecurityDomain("keycloak")
>      >      > public class PromocionRest {
>      >      > @Context
>      >      > HttpServletRequest request;
>      >      > @Context
>      >      > SecurityContext securityContext;
>      >      > @Resource
>      >      > SessionContext sc;
>      >      > @GET
>      >      > @Produces("application/json")
>      >      > @Path("/list")
>      >      > //@RolesAllowed({ "user" }) <-- If I use this annotation y
>     get an
>      >     error.
>      >      > @PermitAll
>      >      > public RespuestaListaBase<Promocion> listadoPromociones(...){
>      >      > KeycloakPrincipal principal =
>      >      > (KeycloakPrincipal)securityContext.getUserPrincipal();
>      >      > KeycloakSecurityContext session = (KeycloakSecurityContext)
>      >      > request.getAttribute(KeycloakSecurityContext.class.getName());
>      >      > if (sc!=null && sc.getCallerPrincipal()!=null){
>      >      > System.out.println("Principal's name according to EJB: " +
>      >      > sc.getCallerPrincipal().getName());
>      >      > }
>      >      >
>      >      > System.out.println("Is user in role 'user'? " +
>      >      > request.isUserInRole("user"));
>      >      >
>      >      > String token = request.getHeader("authorization");
>      >      > HttpClient client = new
>      >     HttpClientBuilder().disableTrustManager().build();
>      >      > try {
>      >      > String url = request.getRequestURL().toString();
>      >      > url = url.substring(0, url.indexOf('/', 8));
>      >      > HttpGet get = new HttpGet(url +
>     "/auth/admin/realms/demo/roles");
>      >      > get.addHeader("Authorization", "Bearer " + token);
>      >      > try {
>      >      > HttpResponse response = client.execute(get);
>      >      > if (response.getStatusLine().getStatusCode() != 200) {
>      >      > //throw new Failure(response.getStatusLine().getStatusCode());
>      >      > }
>      >      > HttpEntity entity = response.getEntity();
>      >      > InputStream is = entity.getContent();
>      >      >
>      >      > } catch (IOException e) {
>      >      > throw new RuntimeException(e);
>      >      > }
>      >      > } finally {
>      >      > client.getConnectionManager().shutdown();
>      >      > }
>      >      > }
>      >      > }
>      >      >
>      >      > I also have configured jboss-web.xml like this:
>      >      > <jboss-web>
>      >      > <security-domain>keycloak</security-domain>
>      >      > </jboss-web>
>      >      >
>      >      > And web.xml like this:
>      >      > <login-config>
>      >      > <auth-method>KEYCLOAK</auth-method>
>      >      > <realm-name>demo</realm-name>
>      >      > </login-config>
>      >      >
>      >      > <security-role>
>      >      > <role-name>user</role-name>
>      >      > </security-role>
>      >      >
>      >      > Some notes about the code:
>      >      > - KeycloakPrincipal principal =
>      >      > (KeycloakPrincipal)securityContext.getUserPrincipal(); <--
>      >     principal is
>      >      > always null
>      >      > - KeycloakSecurityContext session = (KeycloakSecurityContext)
>      >      > request.getAttribute(KeycloakSecurityContext.class.getName());
>      >     <-- session
>      >      > is always null
>      >      > - sc.getCallerPrincipal().getName() <-- returns
>     'anonymous', so
>      >     it seems it
>      >      > isn't taking security-domain?
>      >      > - request.isUserInRole("user") <-- returns null
>      >      > - HttpResponse response = client.execute(get) <-- throws an
>      >     exception:
>      >      > org.jboss.resteasy.spi.UnauthorizedException: Bearer
>      >      > - If I use @RolesAllowed({ "user" }) annotation I get this
>     error:
>      >     JBAS014502:
>      >      > The invocation is not allowed in the method
>      >      > - String token = request.getHeader("authorization"); <-- I get
>      >      > 'Authorization:Bearer eyJhbGciOiJSUzI1Ni...'
>      >      >
>      >      > I suppose i'm doing it wrong, but I don't know what is the
>      >     correct form.
>      >      > Could I get user information from token received?
>      >      >
>      >      > Thanks in advance,
>      >      > Juan Escot
>      >      >
>      >      > _______________________________________________
>      >      > 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
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > 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

From bburke at redhat.com  Thu Jan 22 15:14:13 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 22 Jan 2015 15:14:13 -0500
Subject: [keycloak-dev] aggregate modules
Message-ID: <54C15A15.50108@redhat.com>

Hey,

I was thinking of having a few aggregate modules instead of having one 
jboss-deployment-structure.xml that includes everything (50+ modules).

keycloak-server - includes base SPIs and keycloak-providers module
keycloak-adapter
keycloak-providers - includes JPA and infinispan providers by default
keycloak-mongo-providers - all stuff that uses mongo
keycloak-jpa-providers - all stuff that uses jpa
keycloak-infinispan-providers - all stuff that uses infinispan
keycloak-social-plugins - all social provider plugins

This way, if dependencies need to be added/removed/modified, you don't 
have to edit the WAR.

Sorry I've taken so long...  A lot of distractions this week.


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

From ssilvert at redhat.com  Thu Jan 22 16:25:22 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 22 Jan 2015 16:25:22 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C15A15.50108@redhat.com>
References: <54C15A15.50108@redhat.com>
Message-ID: <54C16AC2.3020606@redhat.com>

You could also try using aggregator modules like org.jboss.as.aggregate 
and javaee.api.  That way, you retain the flexibility of having each jar 
in its own module but you can still reference the groups.

BTW, I'm back up and running.  Woo Hooooo!

On 1/22/2015 3:14 PM, Bill Burke wrote:
> Hey,
>
> I was thinking of having a few aggregate modules instead of having one
> jboss-deployment-structure.xml that includes everything (50+ modules).
>
> keycloak-server - includes base SPIs and keycloak-providers module
> keycloak-adapter
> keycloak-providers - includes JPA and infinispan providers by default
> keycloak-mongo-providers - all stuff that uses mongo
> keycloak-jpa-providers - all stuff that uses jpa
> keycloak-infinispan-providers - all stuff that uses infinispan
> keycloak-social-plugins - all social provider plugins
>
> This way, if dependencies need to be added/removed/modified, you don't
> have to edit the WAR.
>
> Sorry I've taken so long...  A lot of distractions this week.
>
>


From ssilvert at redhat.com  Thu Jan 22 16:49:05 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 22 Jan 2015 16:49:05 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C16AC2.3020606@redhat.com>
References: <54C15A15.50108@redhat.com> <54C16AC2.3020606@redhat.com>
Message-ID: <54C17051.5030806@redhat.com>

On 1/22/2015 4:25 PM, Stan Silvert wrote:
> You could also try using aggregator modules like org.jboss.as.aggregate
> and javaee.api.  That way, you retain the flexibility of having each jar
> in its own module but you can still reference the groups.
I just realized that this is probably what you were talking about.

You'll still retain one module per jar?
>
> BTW, I'm back up and running.  Woo Hooooo!
>
> On 1/22/2015 3:14 PM, Bill Burke wrote:
>> Hey,
>>
>> I was thinking of having a few aggregate modules instead of having one
>> jboss-deployment-structure.xml that includes everything (50+ modules).
>>
>> keycloak-server - includes base SPIs and keycloak-providers module
>> keycloak-adapter
>> keycloak-providers - includes JPA and infinispan providers by default
>> keycloak-mongo-providers - all stuff that uses mongo
>> keycloak-jpa-providers - all stuff that uses jpa
>> keycloak-infinispan-providers - all stuff that uses infinispan
>> keycloak-social-plugins - all social provider plugins
>>
>> This way, if dependencies need to be added/removed/modified, you don't
>> have to edit the WAR.
>>
>> Sorry I've taken so long...  A lot of distractions this week.
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Jan 22 17:29:43 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 22 Jan 2015 17:29:43 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C17051.5030806@redhat.com>
References: <54C15A15.50108@redhat.com> <54C16AC2.3020606@redhat.com>
	<54C17051.5030806@redhat.com>
Message-ID: <54C179D7.4080500@redhat.com>

One module per jar, yes...

Finished all the modules, now setting things up....Sorry, I'm distracted 
by deflategate and superbowl this week :)

On 1/22/2015 4:49 PM, Stan Silvert wrote:
> On 1/22/2015 4:25 PM, Stan Silvert wrote:
>> You could also try using aggregator modules like org.jboss.as.aggregate
>> and javaee.api.  That way, you retain the flexibility of having each jar
>> in its own module but you can still reference the groups.
> I just realized that this is probably what you were talking about.
>
> You'll still retain one module per jar?
>>
>> BTW, I'm back up and running.  Woo Hooooo!
>>
>> On 1/22/2015 3:14 PM, Bill Burke wrote:
>>> Hey,
>>>
>>> I was thinking of having a few aggregate modules instead of having one
>>> jboss-deployment-structure.xml that includes everything (50+ modules).
>>>
>>> keycloak-server - includes base SPIs and keycloak-providers module
>>> keycloak-adapter
>>> keycloak-providers - includes JPA and infinispan providers by default
>>> keycloak-mongo-providers - all stuff that uses mongo
>>> keycloak-jpa-providers - all stuff that uses jpa
>>> keycloak-infinispan-providers - all stuff that uses infinispan
>>> keycloak-social-plugins - all social provider plugins
>>>
>>> This way, if dependencies need to be added/removed/modified, you don't
>>> have to edit the WAR.
>>>
>>> Sorry I've taken so long...  A lot of distractions this week.
>>>
>>>
>> _______________________________________________
>> 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 stian at redhat.com  Fri Jan 23 02:28:48 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 02:28:48 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C179D7.4080500@redhat.com>
References: <54C15A15.50108@redhat.com> <54C16AC2.3020606@redhat.com>
	<54C17051.5030806@redhat.com> <54C179D7.4080500@redhat.com>
Message-ID: <915584331.15666194.1421998128824.JavaMail.zimbra@redhat.com>

Aggregate modules sounds good to me.

Your distractions sounds more fun than mine. I've been scraping wall paper and filling plaster boards ;)


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, January 22, 2015 11:29:43 PM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> One module per jar, yes...
> 
> Finished all the modules, now setting things up....Sorry, I'm distracted
> by deflategate and superbowl this week :)
> 
> On 1/22/2015 4:49 PM, Stan Silvert wrote:
> > On 1/22/2015 4:25 PM, Stan Silvert wrote:
> >> You could also try using aggregator modules like org.jboss.as.aggregate
> >> and javaee.api.  That way, you retain the flexibility of having each jar
> >> in its own module but you can still reference the groups.
> > I just realized that this is probably what you were talking about.
> >
> > You'll still retain one module per jar?
> >>
> >> BTW, I'm back up and running.  Woo Hooooo!
> >>
> >> On 1/22/2015 3:14 PM, Bill Burke wrote:
> >>> Hey,
> >>>
> >>> I was thinking of having a few aggregate modules instead of having one
> >>> jboss-deployment-structure.xml that includes everything (50+ modules).
> >>>
> >>> keycloak-server - includes base SPIs and keycloak-providers module
> >>> keycloak-adapter
> >>> keycloak-providers - includes JPA and infinispan providers by default
> >>> keycloak-mongo-providers - all stuff that uses mongo
> >>> keycloak-jpa-providers - all stuff that uses jpa
> >>> keycloak-infinispan-providers - all stuff that uses infinispan
> >>> keycloak-social-plugins - all social provider plugins
> >>>
> >>> This way, if dependencies need to be added/removed/modified, you don't
> >>> have to edit the WAR.
> >>>
> >>> Sorry I've taken so long...  A lot of distractions this week.
> >>>
> >>>
> >> _______________________________________________
> >> 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 stian at redhat.com  Fri Jan 23 06:23:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 06:23:54 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1536195383.15786091.1422011705606.JavaMail.zimbra@redhat.com>
Message-ID: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>

Our URLs are quite long, examples:

* http://localhost:8080/auth/realms/master/protocols/openid-connect/login
* http://localhost:8080/auth/realms/master/account

We could remove the 'realms' part and 'protocols' parts couldn't we?

* http://localhost:8080/auth/master/oidc/login
* http://localhost:8080/auth/master/account

That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.

We also need to make sure we can just the root context:

* http://localhost:8080/master/oidc/login
* http://localhost:8080/master/account

We can also introduce other mechanisms to select the realm. For example a server with single realm can just omit it altogether:

* http://localhost:8080/oidc/login
* http://localhost:8080/account

And we could allow setting what domains uses what realms:

* http://keycloak-master/oidc/login
* http://keycloak-other/oidc/login



From ssilvert at redhat.com  Fri Jan 23 08:01:23 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 23 Jan 2015 08:01:23 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
Message-ID: <54C24623.4010902@redhat.com>

I like the idea of an option to bind the auth server to the root 
context.   I think that would be especially good for the appliance dist.

But I'm not sure about the rest.  What is the problem we are solving?

On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> Our URLs are quite long, examples:
>
> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> * http://localhost:8080/auth/realms/master/account
>
> We could remove the 'realms' part and 'protocols' parts couldn't we?
>
> * http://localhost:8080/auth/master/oidc/login
> * http://localhost:8080/auth/master/account
>
> That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.
>
> We also need to make sure we can just the root context:
>
> * http://localhost:8080/master/oidc/login
> * http://localhost:8080/master/account
>
> We can also introduce other mechanisms to select the realm. For example a server with single realm can just omit it altogether:
>
> * http://localhost:8080/oidc/login
> * http://localhost:8080/account
>
> And we could allow setting what domains uses what realms:
>
> * http://keycloak-master/oidc/login
> * http://keycloak-other/oidc/login
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Jan 23 08:06:01 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 08:06:01 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C24623.4010902@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C24623.4010902@redhat.com>
Message-ID: <2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, January 23, 2015 2:01:23 PM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> I like the idea of an option to bind the auth server to the root
> context.   I think that would be especially good for the appliance dist.
> 
> But I'm not sure about the rest.  What is the problem we are solving?

Shorter and easier to remember URLs ;)

At least one the account will be something that users access directly.

> 
> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> > Our URLs are quite long, examples:
> >
> > * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> > * http://localhost:8080/auth/realms/master/account
> >
> > We could remove the 'realms' part and 'protocols' parts couldn't we?
> >
> > * http://localhost:8080/auth/master/oidc/login
> > * http://localhost:8080/auth/master/account
> >
> > That would require moving everything under a realm and I guess we'd need to
> > hard-wire the protocols, but I think that should be fine.
> >
> > We also need to make sure we can just the root context:
> >
> > * http://localhost:8080/master/oidc/login
> > * http://localhost:8080/master/account
> >
> > We can also introduce other mechanisms to select the realm. For example a
> > server with single realm can just omit it altogether:
> >
> > * http://localhost:8080/oidc/login
> > * http://localhost:8080/account
> >
> > And we could allow setting what domains uses what realms:
> >
> > * http://keycloak-master/oidc/login
> > * http://keycloak-other/oidc/login
> >
> >
> > _______________________________________________
> > 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  Fri Jan 23 08:10:00 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 23 Jan 2015 08:10:00 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C24623.4010902@redhat.com>
	<2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>
Message-ID: <54C24828.8040503@redhat.com>

On 1/23/2015 8:06 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, January 23, 2015 2:01:23 PM
>> Subject: Re: [keycloak-dev] Shortening URLs
>>
>> I like the idea of an option to bind the auth server to the root
>> context.   I think that would be especially good for the appliance dist.
>>
>> But I'm not sure about the rest.  What is the problem we are solving?
> Shorter and easier to remember URLs ;)
>
> At least one the account will be something that users access directly.
Which one is the URL that they will need to remember?  Maybe we could 
make an alias.
>
>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>> Our URLs are quite long, examples:
>>>
>>> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>> * http://localhost:8080/auth/realms/master/account
>>>
>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>
>>> * http://localhost:8080/auth/master/oidc/login
>>> * http://localhost:8080/auth/master/account
>>>
>>> That would require moving everything under a realm and I guess we'd need to
>>> hard-wire the protocols, but I think that should be fine.
>>>
>>> We also need to make sure we can just the root context:
>>>
>>> * http://localhost:8080/master/oidc/login
>>> * http://localhost:8080/master/account
>>>
>>> We can also introduce other mechanisms to select the realm. For example a
>>> server with single realm can just omit it altogether:
>>>
>>> * http://localhost:8080/oidc/login
>>> * http://localhost:8080/account
>>>
>>> And we could allow setting what domains uses what realms:
>>>
>>> * http://keycloak-master/oidc/login
>>> * http://keycloak-other/oidc/login
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Fri Jan 23 08:20:11 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 08:20:11 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C24828.8040503@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C24623.4010902@redhat.com>
	<2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>
	<54C24828.8040503@redhat.com>
Message-ID: <1626261247.15836730.1422019211918.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, January 23, 2015 2:10:00 PM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> On 1/23/2015 8:06 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, January 23, 2015 2:01:23 PM
> >> Subject: Re: [keycloak-dev] Shortening URLs
> >>
> >> I like the idea of an option to bind the auth server to the root
> >> context.   I think that would be especially good for the appliance dist.
> >>
> >> But I'm not sure about the rest.  What is the problem we are solving?
> > Shorter and easier to remember URLs ;)
> >
> > At least one the account will be something that users access directly.
> Which one is the URL that they will need to remember?  Maybe we could
> make an alias.

Account is accessible by users directly:
- http://localhost:8080/auth/realms/master/account

BTW why not change it? If it can make things simpler for users. Devs that don't use our adapters, but use standard openid connect libs for example, will need to figure out all urls and configure them in the lib their using.

> >
> >> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> >>> Our URLs are quite long, examples:
> >>>
> >>> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> >>> * http://localhost:8080/auth/realms/master/account
> >>>
> >>> We could remove the 'realms' part and 'protocols' parts couldn't we?
> >>>
> >>> * http://localhost:8080/auth/master/oidc/login
> >>> * http://localhost:8080/auth/master/account
> >>>
> >>> That would require moving everything under a realm and I guess we'd need
> >>> to
> >>> hard-wire the protocols, but I think that should be fine.
> >>>
> >>> We also need to make sure we can just the root context:
> >>>
> >>> * http://localhost:8080/master/oidc/login
> >>> * http://localhost:8080/master/account
> >>>
> >>> We can also introduce other mechanisms to select the realm. For example a
> >>> server with single realm can just omit it altogether:
> >>>
> >>> * http://localhost:8080/oidc/login
> >>> * http://localhost:8080/account
> >>>
> >>> And we could allow setting what domains uses what realms:
> >>>
> >>> * http://keycloak-master/oidc/login
> >>> * http://keycloak-other/oidc/login
> >>>
> >>>
> >>> _______________________________________________
> >>> 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 Jan 23 08:25:34 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 23 Jan 2015 08:25:34 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
Message-ID: <2051808458.14072541.1422019534198.JavaMail.zimbra@redhat.com>

+1. And for OIDC endpoints, we still need to review them some time.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Friday, January 23, 2015 9:23:54 AM
Subject: [keycloak-dev] Shortening URLs

Our URLs are quite long, examples:

* http://localhost:8080/auth/realms/master/protocols/openid-connect/login
* http://localhost:8080/auth/realms/master/account

We could remove the 'realms' part and 'protocols' parts couldn't we?

* http://localhost:8080/auth/master/oidc/login
* http://localhost:8080/auth/master/account

That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.

We also need to make sure we can just the root context:

* http://localhost:8080/master/oidc/login
* http://localhost:8080/master/account

We can also introduce other mechanisms to select the realm. For example a server with single realm can just omit it altogether:

* http://localhost:8080/oidc/login
* http://localhost:8080/account

And we could allow setting what domains uses what realms:

* http://keycloak-master/oidc/login
* http://keycloak-other/oidc/login


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

From psilva at redhat.com  Fri Jan 23 08:27:19 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 23 Jan 2015 08:27:19 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <2051808458.14072541.1422019534198.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<2051808458.14072541.1422019534198.JavaMail.zimbra@redhat.com>
Message-ID: <188130425.14073041.1422019639540.JavaMail.zimbra@redhat.com>

However, I think we may need to keep /auth. It may be useful to reference the whole server regardless a specific realm.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Friday, January 23, 2015 11:25:34 AM
Subject: Re: [keycloak-dev] Shortening URLs

+1. And for OIDC endpoints, we still need to review them some time.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Friday, January 23, 2015 9:23:54 AM
Subject: [keycloak-dev] Shortening URLs

Our URLs are quite long, examples:

* http://localhost:8080/auth/realms/master/protocols/openid-connect/login
* http://localhost:8080/auth/realms/master/account

We could remove the 'realms' part and 'protocols' parts couldn't we?

* http://localhost:8080/auth/master/oidc/login
* http://localhost:8080/auth/master/account

That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.

We also need to make sure we can just the root context:

* http://localhost:8080/master/oidc/login
* http://localhost:8080/master/account

We can also introduce other mechanisms to select the realm. For example a server with single realm can just omit it altogether:

* http://localhost:8080/oidc/login
* http://localhost:8080/account

And we could allow setting what domains uses what realms:

* http://keycloak-master/oidc/login
* http://keycloak-other/oidc/login


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

From stian at redhat.com  Fri Jan 23 08:32:47 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 08:32:47 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <188130425.14073041.1422019639540.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<2051808458.14072541.1422019534198.JavaMail.zimbra@redhat.com>
	<188130425.14073041.1422019639540.JavaMail.zimbra@redhat.com>
Message-ID: <1351733626.15842563.1422019967904.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 23, 2015 2:27:19 PM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> However, I think we may need to keep /auth. It may be useful to reference the
> whole server regardless a specific realm.

/auth isn't needed if Keycloak is running as a separate server and has it's own domain for example https://auth.acme.org

> 
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 23, 2015 11:25:34 AM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> +1. And for OIDC endpoints, we still need to review them some time.
> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 23, 2015 9:23:54 AM
> Subject: [keycloak-dev] Shortening URLs
> 
> Our URLs are quite long, examples:
> 
> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> * http://localhost:8080/auth/realms/master/account
> 
> We could remove the 'realms' part and 'protocols' parts couldn't we?
> 
> * http://localhost:8080/auth/master/oidc/login
> * http://localhost:8080/auth/master/account
> 
> That would require moving everything under a realm and I guess we'd need to
> hard-wire the protocols, but I think that should be fine.
> 
> We also need to make sure we can just the root context:
> 
> * http://localhost:8080/master/oidc/login
> * http://localhost:8080/master/account
> 
> We can also introduce other mechanisms to select the realm. For example a
> server with single realm can just omit it altogether:
> 
> * http://localhost:8080/oidc/login
> * http://localhost:8080/account
> 
> And we could allow setting what domains uses what realms:
> 
> * http://keycloak-master/oidc/login
> * http://keycloak-other/oidc/login
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From guydavis.ca at gmail.com  Fri Jan 23 08:39:04 2015
From: guydavis.ca at gmail.com (Guy Davis)
Date: Fri, 23 Jan 2015 06:39:04 -0700
Subject: [keycloak-dev] Building Keycloak from master
Message-ID: <CAAgmn1ou2FYOhPOtYj2DYK4F5kVFW=JVixW_p_zB5z_aBfEcJg@mail.gmail.com>

Good day,

I've been able to get the 1.1.0.Beta2 distribution running inside my JBoss
EAP 6.1alpha with the JBoss 7 adapter.  However, I would like to try the
latest work related to identity brokering by building the master branch. I
couldn't find build instructions in the master checkout from Git, so tried
the following generic steps:

   1. mvn compile  --> Succeeded
   2. mvn package  --> Failed with test errors.

It would be great if you could point me to the steps to build master into a
distribution that I could then deploy into my local JBoss.  I'm very much
looking forward to trying out the latest work.

Thanks much,
Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150123/f69b7517/attachment.html 

From ssilvert at redhat.com  Fri Jan 23 08:43:59 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 23 Jan 2015 08:43:59 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <188130425.14073041.1422019639540.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<2051808458.14072541.1422019534198.JavaMail.zimbra@redhat.com>
	<188130425.14073041.1422019639540.JavaMail.zimbra@redhat.com>
Message-ID: <54C2501F.3030801@redhat.com>

On 1/23/2015 8:27 AM, Pedro Igor Silva wrote:
> However, I think we may need to keep /auth. It may be useful to reference the whole server regardless a specific realm.
auth can just be the root context.  You can do that with Keycloak 
today.  But we could make it easier to configure it.
>
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 23, 2015 11:25:34 AM
> Subject: Re: [keycloak-dev] Shortening URLs
>
> +1. And for OIDC endpoints, we still need to review them some time.
>
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 23, 2015 9:23:54 AM
> Subject: [keycloak-dev] Shortening URLs
>
> Our URLs are quite long, examples:
>
> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> * http://localhost:8080/auth/realms/master/account
>
> We could remove the 'realms' part and 'protocols' parts couldn't we?
>
> * http://localhost:8080/auth/master/oidc/login
> * http://localhost:8080/auth/master/account
>
> That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.
>
> We also need to make sure we can just the root context:
>
> * http://localhost:8080/master/oidc/login
> * http://localhost:8080/master/account
>
> We can also introduce other mechanisms to select the realm. For example a server with single realm can just omit it altogether:
>
> * http://localhost:8080/oidc/login
> * http://localhost:8080/account
>
> And we could allow setting what domains uses what realms:
>
> * http://keycloak-master/oidc/login
> * http://keycloak-other/oidc/login
>
>
> _______________________________________________
> 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  Fri Jan 23 08:45:20 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 23 Jan 2015 08:45:20 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1626261247.15836730.1422019211918.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C24623.4010902@redhat.com>
	<2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>
	<54C24828.8040503@redhat.com>
	<1626261247.15836730.1422019211918.JavaMail.zimbra@redhat.com>
Message-ID: <54C25070.3000603@redhat.com>

I'm just thinking that we need to be careful about future name 
collisions.  For instance, if we need a URL that applies to the entire 
auth server and we name it "foo" you would get a URL like this:
http://localhost:8080/auth/foo/

Then without the "realms" part of the URL someone could name their realm 
foo and you would get a collision.

So if it's something the user needs to remember, let's make it super easy:

http://foo.com/stan

Of course then we would need to either enforce that they only create one 
realm  So for multiple realms we could make it:

http://realm.foo.com/stan

On 1/23/2015 8:20 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, January 23, 2015 2:10:00 PM
>> Subject: Re: [keycloak-dev] Shortening URLs
>>
>> On 1/23/2015 8:06 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, January 23, 2015 2:01:23 PM
>>>> Subject: Re: [keycloak-dev] Shortening URLs
>>>>
>>>> I like the idea of an option to bind the auth server to the root
>>>> context.   I think that would be especially good for the appliance dist.
>>>>
>>>> But I'm not sure about the rest.  What is the problem we are solving?
>>> Shorter and easier to remember URLs ;)
>>>
>>> At least one the account will be something that users access directly.
>> Which one is the URL that they will need to remember?  Maybe we could
>> make an alias.
> Account is accessible by users directly:
> - http://localhost:8080/auth/realms/master/account
>
> BTW why not change it? If it can make things simpler for users. Devs that don't use our adapters, but use standard openid connect libs for example, will need to figure out all urls and configure them in the lib their using.
>
>>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>>>> Our URLs are quite long, examples:
>>>>>
>>>>> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>>>> * http://localhost:8080/auth/realms/master/account
>>>>>
>>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>>>
>>>>> * http://localhost:8080/auth/master/oidc/login
>>>>> * http://localhost:8080/auth/master/account
>>>>>
>>>>> That would require moving everything under a realm and I guess we'd need
>>>>> to
>>>>> hard-wire the protocols, but I think that should be fine.
>>>>>
>>>>> We also need to make sure we can just the root context:
>>>>>
>>>>> * http://localhost:8080/master/oidc/login
>>>>> * http://localhost:8080/master/account
>>>>>
>>>>> We can also introduce other mechanisms to select the realm. For example a
>>>>> server with single realm can just omit it altogether:
>>>>>
>>>>> * http://localhost:8080/oidc/login
>>>>> * http://localhost:8080/account
>>>>>
>>>>> And we could allow setting what domains uses what realms:
>>>>>
>>>>> * http://keycloak-master/oidc/login
>>>>> * http://keycloak-other/oidc/login
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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  Fri Jan 23 08:47:20 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 23 Jan 2015 08:47:20 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C25070.3000603@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C24623.4010902@redhat.com>
	<2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>
	<54C24828.8040503@redhat.com>
	<1626261247.15836730.1422019211918.JavaMail.zimbra@redhat.com>
	<54C25070.3000603@redhat.com>
Message-ID: <54C250E8.8010205@redhat.com>

On 1/23/2015 8:45 AM, Stan Silvert wrote:
> So if it's something the user needs to remember, let's make it super easy:
>
> http://foo.com/stan
>
> Of course then we would need to either enforce that they only create one
> realm  So for multiple realms we could make it:
>
> http://realm.foo.com/stan
I mean http://realmname.foo.com
>
> On 1/23/2015 8:20 AM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Friday, January 23, 2015 2:10:00 PM
>>> Subject: Re: [keycloak-dev] Shortening URLs
>>>
>>> On 1/23/2015 8:06 AM, Stian Thorgersen wrote:
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, January 23, 2015 2:01:23 PM
>>>>> Subject: Re: [keycloak-dev] Shortening URLs
>>>>>
>>>>> I like the idea of an option to bind the auth server to the root
>>>>> context.   I think that would be especially good for the appliance dist.
>>>>>
>>>>> But I'm not sure about the rest.  What is the problem we are solving?
>>>> Shorter and easier to remember URLs ;)
>>>>
>>>> At least one the account will be something that users access directly.
>>> Which one is the URL that they will need to remember?  Maybe we could
>>> make an alias.
>> Account is accessible by users directly:
>> - http://localhost:8080/auth/realms/master/account
>>
>> BTW why not change it? If it can make things simpler for users. Devs that don't use our adapters, but use standard openid connect libs for example, will need to figure out all urls and configure them in the lib their using.
>>
>>>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>>>>> Our URLs are quite long, examples:
>>>>>>
>>>>>> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>>>>> * http://localhost:8080/auth/realms/master/account
>>>>>>
>>>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>>>>
>>>>>> * http://localhost:8080/auth/master/oidc/login
>>>>>> * http://localhost:8080/auth/master/account
>>>>>>
>>>>>> That would require moving everything under a realm and I guess we'd need
>>>>>> to
>>>>>> hard-wire the protocols, but I think that should be fine.
>>>>>>
>>>>>> We also need to make sure we can just the root context:
>>>>>>
>>>>>> * http://localhost:8080/master/oidc/login
>>>>>> * http://localhost:8080/master/account
>>>>>>
>>>>>> We can also introduce other mechanisms to select the realm. For example a
>>>>>> server with single realm can just omit it altogether:
>>>>>>
>>>>>> * http://localhost:8080/oidc/login
>>>>>> * http://localhost:8080/account
>>>>>>
>>>>>> And we could allow setting what domains uses what realms:
>>>>>>
>>>>>> * http://keycloak-master/oidc/login
>>>>>> * http://keycloak-other/oidc/login
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 psilva at redhat.com  Fri Jan 23 08:49:18 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 23 Jan 2015 08:49:18 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1351733626.15842563.1422019967904.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<2051808458.14072541.1422019534198.JavaMail.zimbra@redhat.com>
	<188130425.14073041.1422019639540.JavaMail.zimbra@redhat.com>
	<1351733626.15842563.1422019967904.JavaMail.zimbra@redhat.com>
Message-ID: <1248116234.14085374.1422020958218.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 23, 2015 11:32:47 AM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, January 23, 2015 2:27:19 PM
> > Subject: Re: [keycloak-dev] Shortening URLs
> > 
> > However, I think we may need to keep /auth. It may be useful to reference
> > the
> > whole server regardless a specific realm.
> 
> /auth isn't needed if Keycloak is running as a separate server and has it's
> own domain for example https://auth.acme.org

Yep, if not you may also want to reference a path. But I think that usually you will prefer a separated server for KC, right ?

Also, how the URLs looks like when you are embedding KC into another project ?

> 
> > 
> > ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, January 23, 2015 11:25:34 AM
> > Subject: Re: [keycloak-dev] Shortening URLs
> > 
> > +1. And for OIDC endpoints, we still need to review them some time.
> > 
> > ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, January 23, 2015 9:23:54 AM
> > Subject: [keycloak-dev] Shortening URLs
> > 
> > Our URLs are quite long, examples:
> > 
> > * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> > * http://localhost:8080/auth/realms/master/account
> > 
> > We could remove the 'realms' part and 'protocols' parts couldn't we?
> > 
> > * http://localhost:8080/auth/master/oidc/login
> > * http://localhost:8080/auth/master/account
> > 
> > That would require moving everything under a realm and I guess we'd need to
> > hard-wire the protocols, but I think that should be fine.
> > 
> > We also need to make sure we can just the root context:
> > 
> > * http://localhost:8080/master/oidc/login
> > * http://localhost:8080/master/account
> > 
> > We can also introduce other mechanisms to select the realm. For example a
> > server with single realm can just omit it altogether:
> > 
> > * http://localhost:8080/oidc/login
> > * http://localhost:8080/account
> > 
> > And we could allow setting what domains uses what realms:
> > 
> > * http://keycloak-master/oidc/login
> > * http://keycloak-other/oidc/login
> > 
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From stian at redhat.com  Fri Jan 23 08:51:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 08:51:00 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1248116234.14085374.1422020958218.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<2051808458.14072541.1422019534198.JavaMail.zimbra@redhat.com>
	<188130425.14073041.1422019639540.JavaMail.zimbra@redhat.com>
	<1351733626.15842563.1422019967904.JavaMail.zimbra@redhat.com>
	<1248116234.14085374.1422020958218.JavaMail.zimbra@redhat.com>
Message-ID: <1752623605.15869270.1422021060432.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 23, 2015 2:49:18 PM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, January 23, 2015 11:32:47 AM
> > Subject: Re: [keycloak-dev] Shortening URLs
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, January 23, 2015 2:27:19 PM
> > > Subject: Re: [keycloak-dev] Shortening URLs
> > > 
> > > However, I think we may need to keep /auth. It may be useful to reference
> > > the
> > > whole server regardless a specific realm.
> > 
> > /auth isn't needed if Keycloak is running as a separate server and has it's
> > own domain for example https://auth.acme.org
> 
> Yep, if not you may also want to reference a path. But I think that usually
> you will prefer a separated server for KC, right ?
> 
> Also, how the URLs looks like when you are embedding KC into another project
> ?

That should be configurable by the project, but usually it would be '/auth'

> 
> > 
> > > 
> > > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, January 23, 2015 11:25:34 AM
> > > Subject: Re: [keycloak-dev] Shortening URLs
> > > 
> > > +1. And for OIDC endpoints, we still need to review them some time.
> > > 
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, January 23, 2015 9:23:54 AM
> > > Subject: [keycloak-dev] Shortening URLs
> > > 
> > > Our URLs are quite long, examples:
> > > 
> > > * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> > > * http://localhost:8080/auth/realms/master/account
> > > 
> > > We could remove the 'realms' part and 'protocols' parts couldn't we?
> > > 
> > > * http://localhost:8080/auth/master/oidc/login
> > > * http://localhost:8080/auth/master/account
> > > 
> > > That would require moving everything under a realm and I guess we'd need
> > > to
> > > hard-wire the protocols, but I think that should be fine.
> > > 
> > > We also need to make sure we can just the root context:
> > > 
> > > * http://localhost:8080/master/oidc/login
> > > * http://localhost:8080/master/account
> > > 
> > > We can also introduce other mechanisms to select the realm. For example a
> > > server with single realm can just omit it altogether:
> > > 
> > > * http://localhost:8080/oidc/login
> > > * http://localhost:8080/account
> > > 
> > > And we could allow setting what domains uses what realms:
> > > 
> > > * http://keycloak-master/oidc/login
> > > * http://keycloak-other/oidc/login
> > > 
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

From stian at redhat.com  Fri Jan 23 08:52:04 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 08:52:04 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C250E8.8010205@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C24623.4010902@redhat.com>
	<2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>
	<54C24828.8040503@redhat.com>
	<1626261247.15836730.1422019211918.JavaMail.zimbra@redhat.com>
	<54C25070.3000603@redhat.com> <54C250E8.8010205@redhat.com>
Message-ID: <917873606.15870328.1422021124507.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, January 23, 2015 2:47:20 PM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> On 1/23/2015 8:45 AM, Stan Silvert wrote:
> > So if it's something the user needs to remember, let's make it super easy:
> >
> > http://foo.com/stan
> >
> > Of course then we would need to either enforce that they only create one
> > realm  So for multiple realms we could make it:
> >
> > http://realm.foo.com/stan
> I mean http://realmname.foo.com

I don't think that'll work - if we drop '/realms/' part we would have to move everything under a realm

> >
> > On 1/23/2015 8:20 AM, Stian Thorgersen wrote:
> >> ----- Original Message -----
> >>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>> To: "Stian Thorgersen" <stian at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Friday, January 23, 2015 2:10:00 PM
> >>> Subject: Re: [keycloak-dev] Shortening URLs
> >>>
> >>> On 1/23/2015 8:06 AM, Stian Thorgersen wrote:
> >>>> ----- Original Message -----
> >>>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>>> To: keycloak-dev at lists.jboss.org
> >>>>> Sent: Friday, January 23, 2015 2:01:23 PM
> >>>>> Subject: Re: [keycloak-dev] Shortening URLs
> >>>>>
> >>>>> I like the idea of an option to bind the auth server to the root
> >>>>> context.   I think that would be especially good for the appliance
> >>>>> dist.
> >>>>>
> >>>>> But I'm not sure about the rest.  What is the problem we are solving?
> >>>> Shorter and easier to remember URLs ;)
> >>>>
> >>>> At least one the account will be something that users access directly.
> >>> Which one is the URL that they will need to remember?  Maybe we could
> >>> make an alias.
> >> Account is accessible by users directly:
> >> - http://localhost:8080/auth/realms/master/account
> >>
> >> BTW why not change it? If it can make things simpler for users. Devs that
> >> don't use our adapters, but use standard openid connect libs for example,
> >> will need to figure out all urls and configure them in the lib their
> >> using.
> >>
> >>>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> >>>>>> Our URLs are quite long, examples:
> >>>>>>
> >>>>>> *
> >>>>>> http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> >>>>>> * http://localhost:8080/auth/realms/master/account
> >>>>>>
> >>>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
> >>>>>>
> >>>>>> * http://localhost:8080/auth/master/oidc/login
> >>>>>> * http://localhost:8080/auth/master/account
> >>>>>>
> >>>>>> That would require moving everything under a realm and I guess we'd
> >>>>>> need
> >>>>>> to
> >>>>>> hard-wire the protocols, but I think that should be fine.
> >>>>>>
> >>>>>> We also need to make sure we can just the root context:
> >>>>>>
> >>>>>> * http://localhost:8080/master/oidc/login
> >>>>>> * http://localhost:8080/master/account
> >>>>>>
> >>>>>> We can also introduce other mechanisms to select the realm. For
> >>>>>> example a
> >>>>>> server with single realm can just omit it altogether:
> >>>>>>
> >>>>>> * http://localhost:8080/oidc/login
> >>>>>> * http://localhost:8080/account
> >>>>>>
> >>>>>> And we could allow setting what domains uses what realms:
> >>>>>>
> >>>>>> * http://keycloak-master/oidc/login
> >>>>>> * http://keycloak-other/oidc/login
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> keycloak-dev mailing list
> >>>>>> keycloak-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Jan 23 08:53:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 08:53:07 -0500 (EST)
Subject: [keycloak-dev] Building Keycloak from master
In-Reply-To: <CAAgmn1ou2FYOhPOtYj2DYK4F5kVFW=JVixW_p_zB5z_aBfEcJg@mail.gmail.com>
References: <CAAgmn1ou2FYOhPOtYj2DYK4F5kVFW=JVixW_p_zB5z_aBfEcJg@mail.gmail.com>
Message-ID: <489787969.15871227.1422021187952.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Guy Davis" <guydavis.ca at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, January 23, 2015 2:39:04 PM
> Subject: [keycloak-dev] Building Keycloak from master
> 
> Good day,
> 
> I've been able to get the 1.1.0.Beta2 distribution running inside my JBoss
> EAP 6.1alpha with the JBoss 7 adapter. However, I would like to try the
> latest work related to identity brokering by building the master branch. I
> couldn't find build instructions in the master checkout from Git, so tried
> the following generic steps:
> 
> 
>     1. mvn compile --> Succeeded
>     2. mvn package --> Failed with test errors.
> 
> It would be great if you could point me to the steps to build master into a
> distribution that I could then deploy into my local JBoss. I'm very much
> looking forward to trying out the latest work.

# mvn clean install

There seems to be some tests failing in master atm though

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

From ssilvert at redhat.com  Fri Jan 23 09:06:44 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 23 Jan 2015 09:06:44 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <917873606.15870328.1422021124507.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C24623.4010902@redhat.com>
	<2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>
	<54C24828.8040503@redhat.com>
	<1626261247.15836730.1422019211918.JavaMail.zimbra@redhat.com>
	<54C25070.3000603@redhat.com> <54C250E8.8010205@redhat.com>
	<917873606.15870328.1422021124507.JavaMail.zimbra@redhat.com>
Message-ID: <54C25574.3080207@redhat.com>

On 1/23/2015 8:52 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, January 23, 2015 2:47:20 PM
>> Subject: Re: [keycloak-dev] Shortening URLs
>>
>> On 1/23/2015 8:45 AM, Stan Silvert wrote:
>>> So if it's something the user needs to remember, let's make it super easy:
>>>
>>> http://foo.com/stan
>>>
>>> Of course then we would need to either enforce that they only create one
>>> realm  So for multiple realms we could make it:
>>>
>>> http://realm.foo.com/stan
>> I mean http://realmname.foo.com
> I don't think that'll work - if we drop '/realms/' part we would have to move everything under a realm
The simplified URL would only be for that one use case we need to 
solve.  Everything else would work the old way.

I'm just thinking that if there is something the user needs to memorize 
then we should make it really, really easy to memorize.
>
>>> On 1/23/2015 8:20 AM, Stian Thorgersen wrote:
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, January 23, 2015 2:10:00 PM
>>>>> Subject: Re: [keycloak-dev] Shortening URLs
>>>>>
>>>>> On 1/23/2015 8:06 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Friday, January 23, 2015 2:01:23 PM
>>>>>>> Subject: Re: [keycloak-dev] Shortening URLs
>>>>>>>
>>>>>>> I like the idea of an option to bind the auth server to the root
>>>>>>> context.   I think that would be especially good for the appliance
>>>>>>> dist.
>>>>>>>
>>>>>>> But I'm not sure about the rest.  What is the problem we are solving?
>>>>>> Shorter and easier to remember URLs ;)
>>>>>>
>>>>>> At least one the account will be something that users access directly.
>>>>> Which one is the URL that they will need to remember?  Maybe we could
>>>>> make an alias.
>>>> Account is accessible by users directly:
>>>> - http://localhost:8080/auth/realms/master/account
>>>>
>>>> BTW why not change it? If it can make things simpler for users. Devs that
>>>> don't use our adapters, but use standard openid connect libs for example,
>>>> will need to figure out all urls and configure them in the lib their
>>>> using.
>>>>
>>>>>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>>>>>>> Our URLs are quite long, examples:
>>>>>>>>
>>>>>>>> *
>>>>>>>> http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>>>>>>> * http://localhost:8080/auth/realms/master/account
>>>>>>>>
>>>>>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>>>>>>
>>>>>>>> * http://localhost:8080/auth/master/oidc/login
>>>>>>>> * http://localhost:8080/auth/master/account
>>>>>>>>
>>>>>>>> That would require moving everything under a realm and I guess we'd
>>>>>>>> need
>>>>>>>> to
>>>>>>>> hard-wire the protocols, but I think that should be fine.
>>>>>>>>
>>>>>>>> We also need to make sure we can just the root context:
>>>>>>>>
>>>>>>>> * http://localhost:8080/master/oidc/login
>>>>>>>> * http://localhost:8080/master/account
>>>>>>>>
>>>>>>>> We can also introduce other mechanisms to select the realm. For
>>>>>>>> example a
>>>>>>>> server with single realm can just omit it altogether:
>>>>>>>>
>>>>>>>> * http://localhost:8080/oidc/login
>>>>>>>> * http://localhost:8080/account
>>>>>>>>
>>>>>>>> And we could allow setting what domains uses what realms:
>>>>>>>>
>>>>>>>> * http://keycloak-master/oidc/login
>>>>>>>> * http://keycloak-other/oidc/login
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Fri Jan 23 09:13:02 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 09:13:02 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C25574.3080207@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<2063937645.15828355.1422018361594.JavaMail.zimbra@redhat.com>
	<54C24828.8040503@redhat.com>
	<1626261247.15836730.1422019211918.JavaMail.zimbra@redhat.com>
	<54C25070.3000603@redhat.com> <54C250E8.8010205@redhat.com>
	<917873606.15870328.1422021124507.JavaMail.zimbra@redhat.com>
	<54C25574.3080207@redhat.com>
Message-ID: <1945846998.15887204.1422022382763.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, January 23, 2015 3:06:44 PM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> On 1/23/2015 8:52 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, January 23, 2015 2:47:20 PM
> >> Subject: Re: [keycloak-dev] Shortening URLs
> >>
> >> On 1/23/2015 8:45 AM, Stan Silvert wrote:
> >>> So if it's something the user needs to remember, let's make it super
> >>> easy:
> >>>
> >>> http://foo.com/stan
> >>>
> >>> Of course then we would need to either enforce that they only create one
> >>> realm  So for multiple realms we could make it:
> >>>
> >>> http://realm.foo.com/stan
> >> I mean http://realmname.foo.com
> > I don't think that'll work - if we drop '/realms/' part we would have to
> > move everything under a realm
> The simplified URL would only be for that one use case we need to
> solve.  Everything else would work the old way.
> 
> I'm just thinking that if there is something the user needs to memorize
> then we should make it really, really easy to memorize.

What I suggested in the first place makes everything much easier.

> >
> >>> On 1/23/2015 8:20 AM, Stian Thorgersen wrote:
> >>>> ----- Original Message -----
> >>>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Friday, January 23, 2015 2:10:00 PM
> >>>>> Subject: Re: [keycloak-dev] Shortening URLs
> >>>>>
> >>>>> On 1/23/2015 8:06 AM, Stian Thorgersen wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Friday, January 23, 2015 2:01:23 PM
> >>>>>>> Subject: Re: [keycloak-dev] Shortening URLs
> >>>>>>>
> >>>>>>> I like the idea of an option to bind the auth server to the root
> >>>>>>> context.   I think that would be especially good for the appliance
> >>>>>>> dist.
> >>>>>>>
> >>>>>>> But I'm not sure about the rest.  What is the problem we are solving?
> >>>>>> Shorter and easier to remember URLs ;)
> >>>>>>
> >>>>>> At least one the account will be something that users access directly.
> >>>>> Which one is the URL that they will need to remember?  Maybe we could
> >>>>> make an alias.
> >>>> Account is accessible by users directly:
> >>>> - http://localhost:8080/auth/realms/master/account
> >>>>
> >>>> BTW why not change it? If it can make things simpler for users. Devs
> >>>> that
> >>>> don't use our adapters, but use standard openid connect libs for
> >>>> example,
> >>>> will need to figure out all urls and configure them in the lib their
> >>>> using.
> >>>>
> >>>>>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> >>>>>>>> Our URLs are quite long, examples:
> >>>>>>>>
> >>>>>>>> *
> >>>>>>>> http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> >>>>>>>> * http://localhost:8080/auth/realms/master/account
> >>>>>>>>
> >>>>>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
> >>>>>>>>
> >>>>>>>> * http://localhost:8080/auth/master/oidc/login
> >>>>>>>> * http://localhost:8080/auth/master/account
> >>>>>>>>
> >>>>>>>> That would require moving everything under a realm and I guess we'd
> >>>>>>>> need
> >>>>>>>> to
> >>>>>>>> hard-wire the protocols, but I think that should be fine.
> >>>>>>>>
> >>>>>>>> We also need to make sure we can just the root context:
> >>>>>>>>
> >>>>>>>> * http://localhost:8080/master/oidc/login
> >>>>>>>> * http://localhost:8080/master/account
> >>>>>>>>
> >>>>>>>> We can also introduce other mechanisms to select the realm. For
> >>>>>>>> example a
> >>>>>>>> server with single realm can just omit it altogether:
> >>>>>>>>
> >>>>>>>> * http://localhost:8080/oidc/login
> >>>>>>>> * http://localhost:8080/account
> >>>>>>>>
> >>>>>>>> And we could allow setting what domains uses what realms:
> >>>>>>>>
> >>>>>>>> * http://keycloak-master/oidc/login
> >>>>>>>> * http://keycloak-other/oidc/login
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> keycloak-dev mailing list
> >>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>> _______________________________________________
> >>>>>>> keycloak-dev mailing list
> >>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From bburke at redhat.com  Fri Jan 23 09:36:09 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 Jan 2015 09:36:09 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
Message-ID: <54C25C59.7030804@redhat.com>



On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> Our URLs are quite long, examples:
>
> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> * http://localhost:8080/auth/realms/master/account
>
> We could remove the 'realms' part and 'protocols' parts couldn't we?
>
> * http://localhost:8080/auth/master/oidc/login
> * http://localhost:8080/auth/master/account
>
> That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.
>

Wouldn't work for multiple reasons.

* protocols/* exists to be able to plugin different protocols (oidc, 
saml, etc.)
* Because of the crappy way JAX-RS dispatch algorithm handles wildcards 
for both resource classes and resource locators we need both a "realms" 
and "protocols" qualifier.

Its really funny you bring this up now because I've renewed my argument 
with JAX-RS JSR just 2 minutes ago!  Synchronicity!


> We also need to make sure we can just the root context:
>
> * http://localhost:8080/master/oidc/login
> * http://localhost:8080/master/account
>
> We can also introduce other mechanisms to select the realm. For example a server with single realm can just omit it altogether:
>
> * http://localhost:8080/oidc/login
> * http://localhost:8080/account
>
> And we could allow setting what domains uses what realms:
>
> * http://keycloak-master/oidc/login
> * http://keycloak-other/oidc/login
>

You don't think its better to have URLS be consistent?


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

From jpkroehling at redhat.com  Fri Jan 23 10:05:45 2015
From: jpkroehling at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Fri, 23 Jan 2015 16:05:45 +0100
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
Message-ID: <54C26349.9020506@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/23/2015 12:23 PM, Stian Thorgersen wrote:
> We also need to make sure we can just the root context:
> 
> * http://localhost:8080/master/oidc/login *
> http://localhost:8080/master/account

Would this be the default? I'm asking because it would make it a bit
more difficult to use the same Wildfly instance with other projects,
like Hawkular/RHQ-Metrics, as they also try to deploy directly on the
root context.

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUwmNJAAoJECKM1e+fkPrXwbYH/1x1rPnKYytSovE/TCRb2Swi
AeDlgEhLR66i1+OiSpoQZvbwri3c4B/4x5l1AItk0DZ9+MZ/ZalFuhYj8BR1S4RA
bQOBZTepkyC3vwNE122yuJdzIFCjM7ZGsoy82hhzy5NjoRHjbUsOZp9V0obqjt4f
EfCRUjnlPOGbLCo88KBvrE2vFthEzrA2kk7oN2JcV6PLmLwIC+j18ix2qdHUCnLf
u7PggnrHGHqd261gb+0LTZWXZIdYc6VuXzOykfPzWZYgzp6A1L7nHEeK3XHRT696
gFob5VRg5SOUJeezQ4wgR2WmOK/oQVYKDpCT+M5Mj+fBq5mOGnCYpg49v3vRxWA=
=LSaR
-----END PGP SIGNATURE-----

From stian at redhat.com  Fri Jan 23 10:14:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 10:14:00 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C26349.9020506@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C26349.9020506@redhat.com>
Message-ID: <788862323.15959763.1422026040275.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, January 23, 2015 4:05:45 PM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/23/2015 12:23 PM, Stian Thorgersen wrote:
> > We also need to make sure we can just the root context:
> > 
> > * http://localhost:8080/master/oidc/login *
> > http://localhost:8080/master/account
> 
> Would this be the default? I'm asking because it would make it a bit
> more difficult to use the same Wildfly instance with other projects,
> like Hawkular/RHQ-Metrics, as they also try to deploy directly on the
> root context.

No, the default would be /auth and that would be where we'd recommend all projects that bundle Keycloak to have it as well

> 
> - - Juca.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJUwmNJAAoJECKM1e+fkPrXwbYH/1x1rPnKYytSovE/TCRb2Swi
> AeDlgEhLR66i1+OiSpoQZvbwri3c4B/4x5l1AItk0DZ9+MZ/ZalFuhYj8BR1S4RA
> bQOBZTepkyC3vwNE122yuJdzIFCjM7ZGsoy82hhzy5NjoRHjbUsOZp9V0obqjt4f
> EfCRUjnlPOGbLCo88KBvrE2vFthEzrA2kk7oN2JcV6PLmLwIC+j18ix2qdHUCnLf
> u7PggnrHGHqd261gb+0LTZWXZIdYc6VuXzOykfPzWZYgzp6A1L7nHEeK3XHRT696
> gFob5VRg5SOUJeezQ4wgR2WmOK/oQVYKDpCT+M5Mj+fBq5mOGnCYpg49v3vRxWA=
> =LSaR
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From jpkroehling at redhat.com  Fri Jan 23 10:14:56 2015
From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Fri, 23 Jan 2015 16:14:56 +0100
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <788862323.15959763.1422026040275.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C26349.9020506@redhat.com>
	<788862323.15959763.1422026040275.JavaMail.zimbra@redhat.com>
Message-ID: <54C26570.7000900@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/23/2015 04:14 PM, Stian Thorgersen wrote:
>> No, the default would be /auth and that would be where we'd
>> recommend all projects that bundle Keycloak to have it as well

Perfect, thanks :-)

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUwmVwAAoJECKM1e+fkPrXgvMH/1hGgf8VzbthPVHObqdiAIIt
9InZ8aZ2O25fQRctNmjqiCDO9OJ5fEoS8my3+VS+Ot/Wgqn8hXcdw6ZwEAXVvz/H
tPcOCW28TUncyZa+oA8zazeK20z2wCXt3T8a9QJWNC0vcHsAr32DWVhjYTze1BrW
18/PFgmyZXHO2Fn5fNnDdGMjlMWMkWDPZOVSjYgkyMPV+OI583QDG3Icn2GJESWz
QYbVg9zDdfQtRQ1Ki+lzSxcmep3G5cU2nSRh6H0UZ2BvuqpUPob4/6NipOpfiun9
FYHZO0KVce/YjGeZbWUnz/zCLbTLDpWdyqqo0LnOYB57IBEaB1SO11FIKu+T4rE=
=Ep0R
-----END PGP SIGNATURE-----

From stian at redhat.com  Fri Jan 23 10:15:48 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 23 Jan 2015 10:15:48 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C25C59.7030804@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C25C59.7030804@redhat.com>
Message-ID: <505815031.15960964.1422026148697.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, January 23, 2015 3:36:09 PM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> 
> 
> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> > Our URLs are quite long, examples:
> >
> > * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> > * http://localhost:8080/auth/realms/master/account
> >
> > We could remove the 'realms' part and 'protocols' parts couldn't we?
> >
> > * http://localhost:8080/auth/master/oidc/login
> > * http://localhost:8080/auth/master/account
> >
> > That would require moving everything under a realm and I guess we'd need to
> > hard-wire the protocols, but I think that should be fine.
> >
> 
> Wouldn't work for multiple reasons.
> 
> * protocols/* exists to be able to plugin different protocols (oidc,
> saml, etc.)

Yes, but couldn't we just hard-code it?

> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
> for both resource classes and resource locators we need both a "realms"
> and "protocols" qualifier.

Even if we moved all other paths under /auth/?

> 
> Its really funny you bring this up now because I've renewed my argument
> with JAX-RS JSR just 2 minutes ago!  Synchronicity!
> 
> 
> > We also need to make sure we can just the root context:
> >
> > * http://localhost:8080/master/oidc/login
> > * http://localhost:8080/master/account
> >
> > We can also introduce other mechanisms to select the realm. For example a
> > server with single realm can just omit it altogether:
> >
> > * http://localhost:8080/oidc/login
> > * http://localhost:8080/account
> >
> > And we could allow setting what domains uses what realms:
> >
> > * http://keycloak-master/oidc/login
> > * http://keycloak-other/oidc/login
> >
> 
> You don't think its better to have URLS be consistent?
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Jan 23 10:28:33 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 Jan 2015 10:28:33 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <505815031.15960964.1422026148697.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C25C59.7030804@redhat.com>
	<505815031.15960964.1422026148697.JavaMail.zimbra@redhat.com>
Message-ID: <54C268A1.7040007@redhat.com>



On 1/23/2015 10:15 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, January 23, 2015 3:36:09 PM
>> Subject: Re: [keycloak-dev] Shortening URLs
>>
>>
>>
>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>> Our URLs are quite long, examples:
>>>
>>> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>> * http://localhost:8080/auth/realms/master/account
>>>
>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>
>>> * http://localhost:8080/auth/master/oidc/login
>>> * http://localhost:8080/auth/master/account
>>>
>>> That would require moving everything under a realm and I guess we'd need to
>>> hard-wire the protocols, but I think that should be fine.
>>>
>>
>> Wouldn't work for multiple reasons.
>>
>> * protocols/* exists to be able to plugin different protocols (oidc,
>> saml, etc.)
>
> Yes, but couldn't we just hard-code it?

Go look at the code.  It is implemented to support pluggable protocols. 
  You want to remove that capability just to shorted the URL?

Bill

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

From bburke at redhat.com  Fri Jan 23 10:28:53 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 Jan 2015 10:28:53 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C25C59.7030804@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C25C59.7030804@redhat.com>
Message-ID: <54C268B5.9010903@redhat.com>



On 1/23/2015 9:36 AM, Bill Burke wrote:
>
>
> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>> Our URLs are quite long, examples:
>>
>> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>> * http://localhost:8080/auth/realms/master/account
>>
>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>
>> * http://localhost:8080/auth/master/oidc/login
>> * http://localhost:8080/auth/master/account
>>
>> That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.
>>
>
> Wouldn't work for multiple reasons.
>
> * protocols/* exists to be able to plugin different protocols (oidc,
> saml, etc.)
> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
> for both resource classes and resource locators we need both a "realms"
> and "protocols" qualifier.
>
> Its really funny you bring this up now because I've renewed my argument
> with JAX-RS JSR just 2 minutes ago!  Synchronicity!
>

Bah!  Scratch that...I think we might be able to remove "realms" so long 
as we don't add any other root context wildcard resource classes.  Using 
a wildcard only for "protocols" might paint us in a corner as there may 
be other wildcard resources we want to add in the future.

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

From guydavis.ca at gmail.com  Fri Jan 23 11:46:40 2015
From: guydavis.ca at gmail.com (Guy Davis)
Date: Fri, 23 Jan 2015 09:46:40 -0700
Subject: [keycloak-dev] Building Keycloak from master
In-Reply-To: <489787969.15871227.1422021187952.JavaMail.zimbra@redhat.com>
References: <CAAgmn1ou2FYOhPOtYj2DYK4F5kVFW=JVixW_p_zB5z_aBfEcJg@mail.gmail.com>
	<489787969.15871227.1422021187952.JavaMail.zimbra@redhat.com>
Message-ID: <CAAgmn1o2-FPs__y8Z_kKK+zYCybUVjeGYnEFE3EfSEJir=HU+g@mail.gmail.com>

Hi Stian,

Thanks for the correct maven command.  Yes, the failed tests seem to be
preventing the generation of deployable artifiacts in a 'build' or similar
folder.  Is there anyway to disable unit test execution on master to get
the artifacts to try?

[image: Inline image 1]

Thanks,
Guy

On Fri, Jan 23, 2015 at 6:53 AM, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Guy Davis" <guydavis.ca at gmail.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, January 23, 2015 2:39:04 PM
> > Subject: [keycloak-dev] Building Keycloak from master
> >
> > Good day,
> >
> > I've been able to get the 1.1.0.Beta2 distribution running inside my
> JBoss
> > EAP 6.1alpha with the JBoss 7 adapter. However, I would like to try the
> > latest work related to identity brokering by building the master branch.
> I
> > couldn't find build instructions in the master checkout from Git, so
> tried
> > the following generic steps:
> >
> >
> >     1. mvn compile --> Succeeded
> >     2. mvn package --> Failed with test errors.
> >
> > It would be great if you could point me to the steps to build master
> into a
> > distribution that I could then deploy into my local JBoss. I'm very much
> > looking forward to trying out the latest work.
>
> # mvn clean install
>
> There seems to be some tests failing in master atm though
>
> >
> > Thanks much,
> > Guy
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150123/fe743431/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 40998 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150123/fe743431/attachment-0001.png 

From bburke at redhat.com  Fri Jan 23 13:00:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 Jan 2015 13:00:41 -0500
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C268B5.9010903@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>	<54C25C59.7030804@redhat.com>
	<54C268B5.9010903@redhat.com>
Message-ID: <54C28C49.6010700@redhat.com>

We can't remove "realms" qualifier unless the admin REST interface is 
exposed under an entirely different WAR root context.




On 1/23/2015 10:28 AM, Bill Burke wrote:
>
>
> On 1/23/2015 9:36 AM, Bill Burke wrote:
>>
>>
>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>> Our URLs are quite long, examples:
>>>
>>> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>> * http://localhost:8080/auth/realms/master/account
>>>
>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>
>>> * http://localhost:8080/auth/master/oidc/login
>>> * http://localhost:8080/auth/master/account
>>>
>>> That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.
>>>
>>
>> Wouldn't work for multiple reasons.
>>
>> * protocols/* exists to be able to plugin different protocols (oidc,
>> saml, etc.)
>> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
>> for both resource classes and resource locators we need both a "realms"
>> and "protocols" qualifier.
>>
>> Its really funny you bring this up now because I've renewed my argument
>> with JAX-RS JSR just 2 minutes ago!  Synchronicity!
>>
>
> Bah!  Scratch that...I think we might be able to remove "realms" so long
> as we don't add any other root context wildcard resource classes.  Using
> a wildcard only for "protocols" might paint us in a corner as there may
> be other wildcard resources we want to add in the future.
>

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

From psilva at redhat.com  Fri Jan 23 14:23:19 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 23 Jan 2015 14:23:19 -0500 (EST)
Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
In-Reply-To: <1963218412.14310231.1422037330020.JavaMail.zimbra@redhat.com>
Message-ID: <275977940.14344560.1422040999890.JavaMail.zimbra@redhat.com>

Hi,

    KEYCLOAK-996 is about allowing clients to select an existing identity provider when sending an authentication request to the server. Initially, this is all about passing the IdP id and automatically redirect the user to its login page. Without even show KC's login page.

    IMO instead of using an "idp_hint", like proposed in that JIRA, we may start using the "acr_values" parameter as defined by OIDC specs. I think this parameter better fits the purpose and will allow us to support LoAs in the future as well.

    The acr value in this case would be something like "idp-X", where X is the id of the identity provider.

    What do you think ?

Regards.
Pedro Igor

From bburke at redhat.com  Fri Jan 23 17:53:25 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 23 Jan 2015 17:53:25 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C15A15.50108@redhat.com>
References: <54C15A15.50108@redhat.com>
Message-ID: <54C2D0E5.3030702@redhat.com>

Ran into a wall:

I couldn't have an aggregate module.  service imports didn't seem to 
work so I had to create a dependency for everything within 
jboss-deployment-structure.xml.  I may revisit this as I had a lot of 
errors in my module defintions.

I'm at a wall.  I can't get the JPA connections to find the Hibernate 
provider.  I"m not sure if it can't find persistence.xml or hibernate or 
what.  Tried importing hibernate in various places to no avail.  Error 
Message isn't very helpful either:

javax.persistence.PersistenceException: No Persistence provider for 
EntityManager named keycloak-default

Should we punt on this?  I can't spend much more time on this.

On 1/22/2015 3:14 PM, Bill Burke wrote:
> Hey,
>
> I was thinking of having a few aggregate modules instead of having one
> jboss-deployment-structure.xml that includes everything (50+ modules).
>
> keycloak-server - includes base SPIs and keycloak-providers module
> keycloak-adapter
> keycloak-providers - includes JPA and infinispan providers by default
> keycloak-mongo-providers - all stuff that uses mongo
> keycloak-jpa-providers - all stuff that uses jpa
> keycloak-infinispan-providers - all stuff that uses infinispan
> keycloak-social-plugins - all social provider plugins
>
> This way, if dependencies need to be added/removed/modified, you don't
> have to edit the WAR.
>
> Sorry I've taken so long...  A lot of distractions this week.
>
>

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

From ssilvert at redhat.com  Sat Jan 24 07:00:54 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Sat, 24 Jan 2015 07:00:54 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C2D0E5.3030702@redhat.com>
References: <54C15A15.50108@redhat.com> <54C2D0E5.3030702@redhat.com>
Message-ID: <54C38976.2060807@redhat.com>

On 1/23/2015 5:53 PM, Bill Burke wrote:
> Ran into a wall:
>
> I couldn't have an aggregate module.  service imports didn't seem to
> work so I had to create a dependency for everything within
> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
> errors in my module defintions.
In Brno I can ask David about this.  Can you post your 
jboss-deployment-structure.xml and your aggregate module.xml?
>
> I'm at a wall.  I can't get the JPA connections to find the Hibernate
> provider.  I"m not sure if it can't find persistence.xml or hibernate or
> what.  Tried importing hibernate in various places to no avail.  Error
> Message isn't very helpful either:
>
> javax.persistence.PersistenceException: No Persistence provider for
> EntityManager named keycloak-default
Can you give me a scaled down reproducer for this one?  I can ask around 
and see if anyone knows a solution.
>
> Should we punt on this?  I can't spend much more time on this.
Your analogy is slightly inflated.
>
> On 1/22/2015 3:14 PM, Bill Burke wrote:
>> Hey,
>>
>> I was thinking of having a few aggregate modules instead of having one
>> jboss-deployment-structure.xml that includes everything (50+ modules).
>>
>> keycloak-server - includes base SPIs and keycloak-providers module
>> keycloak-adapter
>> keycloak-providers - includes JPA and infinispan providers by default
>> keycloak-mongo-providers - all stuff that uses mongo
>> keycloak-jpa-providers - all stuff that uses jpa
>> keycloak-infinispan-providers - all stuff that uses infinispan
>> keycloak-social-plugins - all social provider plugins
>>
>> This way, if dependencies need to be added/removed/modified, you don't
>> have to edit the WAR.
>>
>> Sorry I've taken so long...  A lot of distractions this week.
>>
>>


From bburke at redhat.com  Sun Jan 25 21:03:40 2015
From: bburke at redhat.com (Bill Burke)
Date: Sun, 25 Jan 2015 21:03:40 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C38976.2060807@redhat.com>
References: <54C15A15.50108@redhat.com> <54C2D0E5.3030702@redhat.com>
	<54C38976.2060807@redhat.com>
Message-ID: <54C5A07C.1050102@redhat.com>



On 1/24/2015 7:00 AM, Stan Silvert wrote:
> On 1/23/2015 5:53 PM, Bill Burke wrote:
>> Ran into a wall:
>>
>> I couldn't have an aggregate module.  service imports didn't seem to
>> work so I had to create a dependency for everything within
>> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
>> errors in my module defintions.
> In Brno I can ask David about this.  Can you post your
> jboss-deployment-structure.xml and your aggregate module.xml?
>>
>> I'm at a wall.  I can't get the JPA connections to find the Hibernate
>> provider.  I"m not sure if it can't find persistence.xml or hibernate or
>> what.  Tried importing hibernate in various places to no avail.  Error
>> Message isn't very helpful either:
>>
>> javax.persistence.PersistenceException: No Persistence provider for
>> EntityManager named keycloak-default
> Can you give me a scaled down reproducer for this one?  I can ask around
> and see if anyone knows a solution.

I think this is another service import problem.


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

From stian at redhat.com  Mon Jan 26 02:18:14 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 02:18:14 -0500 (EST)
Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
 provider
In-Reply-To: <275977940.14344560.1422040999890.JavaMail.zimbra@redhat.com>
References: <275977940.14344560.1422040999890.JavaMail.zimbra@redhat.com>
Message-ID: <1086360506.239290.1422256694761.JavaMail.zimbra@redhat.com>

Can you elaborate a bit more on the idea? At first glance to me it seems like we'd use one field for two quite different purposes. Level of assurance is abstract (level 0, 1, 2), while authentication mechanism is more concrete (idp-a, password, totp). I think an application might want to request level-1, but not care about mechanism used, while another application would want to select idp-a, but not care about the level of assurance.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, January 23, 2015 8:23:19 PM
> Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
> 
> Hi,
> 
>     KEYCLOAK-996 is about allowing clients to select an existing identity
>     provider when sending an authentication request to the server.
>     Initially, this is all about passing the IdP id and automatically
>     redirect the user to its login page. Without even show KC's login page.
> 
>     IMO instead of using an "idp_hint", like proposed in that JIRA, we may
>     start using the "acr_values" parameter as defined by OIDC specs. I think
>     this parameter better fits the purpose and will allow us to support LoAs
>     in the future as well.
> 
>     The acr value in this case would be something like "idp-X", where X is
>     the id of the identity provider.
> 
>     What do you think ?
> 
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Jan 26 02:43:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 02:43:49 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C5A07C.1050102@redhat.com>
References: <54C15A15.50108@redhat.com> <54C2D0E5.3030702@redhat.com>
	<54C38976.2060807@redhat.com> <54C5A07C.1050102@redhat.com>
Message-ID: <1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 3:03:40 AM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> 
> 
> On 1/24/2015 7:00 AM, Stan Silvert wrote:
> > On 1/23/2015 5:53 PM, Bill Burke wrote:
> >> Ran into a wall:
> >>
> >> I couldn't have an aggregate module.  service imports didn't seem to
> >> work so I had to create a dependency for everything within
> >> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
> >> errors in my module defintions.
> > In Brno I can ask David about this.  Can you post your
> > jboss-deployment-structure.xml and your aggregate module.xml?
> >>
> >> I'm at a wall.  I can't get the JPA connections to find the Hibernate
> >> provider.  I"m not sure if it can't find persistence.xml or hibernate or
> >> what.  Tried importing hibernate in various places to no avail.  Error
> >> Message isn't very helpful either:
> >>
> >> javax.persistence.PersistenceException: No Persistence provider for
> >> EntityManager named keycloak-default
> > Can you give me a scaled down reproducer for this one?  I can ask around
> > and see if anyone knows a solution.
> 
> I think this is another service import problem.

Loading JPA in this way will work, but it's a bit of a PITA. META-INF/persistence.xml isn't exported/imported by default, see https://developer.jboss.org/message/828881#828881

If you're fed up and commit your stuff I can take a look. I've gone done this in the past so should be able to get it to work again.

> 
> 
> --
> 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 christian.beikov at gmail.com  Mon Jan 26 02:46:06 2015
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 26 Jan 2015 08:46:06 +0100
Subject: [keycloak-dev] Direct links to pages
In-Reply-To: <54BC4C53.2050300@gmail.com>
References: <54BC4C53.2050300@gmail.com>
Message-ID: <54C5F0BE.9090002@gmail.com>

Can anyone please confirm that there is or is not a possibility to do this?

Mit freundlichen Gr??en,
------------------------------------------------------------------------
*Christian Beikov*
Am 19.01.2015 um 01:14 schrieb Christian Beikov:
> Hello!
>
> Quick question. Is there a way to directly link to the registration or 
> login page from a different page?
> I tried the following but only get "Bad request" when submitting the form.
>
> Registration: 
> /auth/realms/{realm-name}/tokens/registrations?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fprotected&client_id=protected
> Login: 
> /auth/realms/{realm-name}/tokens/login?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fprotected&client_id=protected
> -- 
>
> Mit freundlichen Gr??en,
> ------------------------------------------------------------------------
> *Christian Beikov*

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

From mposolda at redhat.com  Mon Jan 26 03:51:24 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 26 Jan 2015 09:51:24 +0100
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C28C49.6010700@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>	<54C25C59.7030804@redhat.com>	<54C268B5.9010903@redhat.com>
	<54C28C49.6010700@redhat.com>
Message-ID: <54C6000C.3050503@redhat.com>

The main issue to address are shorter URL for services directly 
accessible by users, which is account mgmt and admin console, right? How 
about introduce aliases and add cookie scoped to '/auth' context, which 
will handle the name of the realm user is logged in?

Some details:

* User will log into realm "foo" . Keycloak will add KEYCLOAK_REALM 
cookie with content "foo" scoped to path "/auth" (or whatever context is 
auth-server deployed on)

* User goes to "/auth/account" . Keycloak will read cookie and redirect 
user to "/auth/realms/foo/account"

* User goes to "/auth/admin" . Keycloak will read cookie and redirect 
user to "/auth/admin/foo/console"

* If user's browser is logged into 2 realms, Keycloak can display the UI 
page with radio buttons where user can choose his realm (Something like 
Google is doing for choosing your account)

* If user is not logged into any realm, Keycloak can display list of all 
realms and user can choose? Or directly redirect user if there is just 
one realm available.


Maybe the behaviour could be somehow pluggable, so people can use 
virtual hosts instead of cookie and access to 
"http://foo.keycloak.org/auth/account" will use realm "foo" etc?

Marek

On 23.1.2015 19:00, Bill Burke wrote:
> We can't remove "realms" qualifier unless the admin REST interface is
> exposed under an entirely different WAR root context.
>
>
>
>
> On 1/23/2015 10:28 AM, Bill Burke wrote:
>>
>> On 1/23/2015 9:36 AM, Bill Burke wrote:
>>>
>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>>> Our URLs are quite long, examples:
>>>>
>>>> * http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>>> * http://localhost:8080/auth/realms/master/account
>>>>
>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>>
>>>> * http://localhost:8080/auth/master/oidc/login
>>>> * http://localhost:8080/auth/master/account
>>>>
>>>> That would require moving everything under a realm and I guess we'd need to hard-wire the protocols, but I think that should be fine.
>>>>
>>> Wouldn't work for multiple reasons.
>>>
>>> * protocols/* exists to be able to plugin different protocols (oidc,
>>> saml, etc.)
>>> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
>>> for both resource classes and resource locators we need both a "realms"
>>> and "protocols" qualifier.
>>>
>>> Its really funny you bring this up now because I've renewed my argument
>>> with JAX-RS JSR just 2 minutes ago!  Synchronicity!
>>>
>> Bah!  Scratch that...I think we might be able to remove "realms" so long
>> as we don't add any other root context wildcard resource classes.  Using
>> a wildcard only for "protocols" might paint us in a corner as there may
>> be other wildcard resources we want to add in the future.
>>


From mposolda at redhat.com  Mon Jan 26 03:53:00 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 26 Jan 2015 09:53:00 +0100
Subject: [keycloak-dev] Building Keycloak from master
In-Reply-To: <CAAgmn1o2-FPs__y8Z_kKK+zYCybUVjeGYnEFE3EfSEJir=HU+g@mail.gmail.com>
References: <CAAgmn1ou2FYOhPOtYj2DYK4F5kVFW=JVixW_p_zB5z_aBfEcJg@mail.gmail.com>	<489787969.15871227.1422021187952.JavaMail.zimbra@redhat.com>
	<CAAgmn1o2-FPs__y8Z_kKK+zYCybUVjeGYnEFE3EfSEJir=HU+g@mail.gmail.com>
Message-ID: <54C6006C.5090909@redhat.com>

Maybe you can try:

mvn clean install -DskipTests=true

Hope it helps,
Marek

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

From stian at redhat.com  Mon Jan 26 04:04:40 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 04:04:40 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C6000C.3050503@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C25C59.7030804@redhat.com> <54C268B5.9010903@redhat.com>
	<54C28C49.6010700@redhat.com> <54C6000C.3050503@redhat.com>
Message-ID: <1529930941.300760.1422263080545.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 9:51:24 AM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> The main issue to address are shorter URL for services directly
> accessible by users, which is account mgmt and admin console, right? How
> about introduce aliases and add cookie scoped to '/auth' context, which
> will handle the name of the realm user is logged in?
> 
> Some details:
> 
> * User will log into realm "foo" . Keycloak will add KEYCLOAK_REALM
> cookie with content "foo" scoped to path "/auth" (or whatever context is
> auth-server deployed on)
> 
> * User goes to "/auth/account" . Keycloak will read cookie and redirect
> user to "/auth/realms/foo/account"
> 
> * User goes to "/auth/admin" . Keycloak will read cookie and redirect
> user to "/auth/admin/foo/console"
> 
> * If user's browser is logged into 2 realms, Keycloak can display the UI
> page with radio buttons where user can choose his realm (Something like
> Google is doing for choosing your account)
> 
> * If user is not logged into any realm, Keycloak can display list of all
> realms and user can choose? Or directly redirect user if there is just
> one realm available.

I don't like that. It will be common for a user that goes directly to 'account' to not be logged-in and the user would have no clue of what realm to select.

Also, how would that work if user logs in to multiple realms?

It's also very much against the whole resign of URLs to have dynamic URLs in such a way.

> 
> 
> Maybe the behaviour could be somehow pluggable, so people can use
> virtual hosts instead of cookie and access to
> "http://foo.keycloak.org/auth/account" will use realm "foo" etc?
> 
> Marek
> 
> On 23.1.2015 19:00, Bill Burke wrote:
> > We can't remove "realms" qualifier unless the admin REST interface is
> > exposed under an entirely different WAR root context.
> >
> >
> >
> >
> > On 1/23/2015 10:28 AM, Bill Burke wrote:
> >>
> >> On 1/23/2015 9:36 AM, Bill Burke wrote:
> >>>
> >>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> >>>> Our URLs are quite long, examples:
> >>>>
> >>>> *
> >>>> http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> >>>> * http://localhost:8080/auth/realms/master/account
> >>>>
> >>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
> >>>>
> >>>> * http://localhost:8080/auth/master/oidc/login
> >>>> * http://localhost:8080/auth/master/account
> >>>>
> >>>> That would require moving everything under a realm and I guess we'd need
> >>>> to hard-wire the protocols, but I think that should be fine.
> >>>>
> >>> Wouldn't work for multiple reasons.
> >>>
> >>> * protocols/* exists to be able to plugin different protocols (oidc,
> >>> saml, etc.)
> >>> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
> >>> for both resource classes and resource locators we need both a "realms"
> >>> and "protocols" qualifier.
> >>>
> >>> Its really funny you bring this up now because I've renewed my argument
> >>> with JAX-RS JSR just 2 minutes ago!  Synchronicity!
> >>>
> >> Bah!  Scratch that...I think we might be able to remove "realms" so long
> >> as we don't add any other root context wildcard resource classes.  Using
> >> a wildcard only for "protocols" might paint us in a corner as there may
> >> be other wildcard resources we want to add in the future.
> >>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Mon Jan 26 04:45:03 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 26 Jan 2015 10:45:03 +0100
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <1529930941.300760.1422263080545.JavaMail.zimbra@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C25C59.7030804@redhat.com> <54C268B5.9010903@redhat.com>
	<54C28C49.6010700@redhat.com> <54C6000C.3050503@redhat.com>
	<1529930941.300760.1422263080545.JavaMail.zimbra@redhat.com>
Message-ID: <54C60C9F.6040201@redhat.com>

On 26.1.2015 10:04, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Monday, January 26, 2015 9:51:24 AM
>> Subject: Re: [keycloak-dev] Shortening URLs
>>
>> The main issue to address are shorter URL for services directly
>> accessible by users, which is account mgmt and admin console, right? How
>> about introduce aliases and add cookie scoped to '/auth' context, which
>> will handle the name of the realm user is logged in?
>>
>> Some details:
>>
>> * User will log into realm "foo" . Keycloak will add KEYCLOAK_REALM
>> cookie with content "foo" scoped to path "/auth" (or whatever context is
>> auth-server deployed on)
>>
>> * User goes to "/auth/account" . Keycloak will read cookie and redirect
>> user to "/auth/realms/foo/account"
>>
>> * User goes to "/auth/admin" . Keycloak will read cookie and redirect
>> user to "/auth/admin/foo/console"
>>
>> * If user's browser is logged into 2 realms, Keycloak can display the UI
>> page with radio buttons where user can choose his realm (Something like
>> Google is doing for choosing your account)
>>
>> * If user is not logged into any realm, Keycloak can display list of all
>> realms and user can choose? Or directly redirect user if there is just
>> one realm available.
> I don't like that. It will be common for a user that goes directly to 'account' to not be logged-in and the user would have no clue of what realm to select.
>
> Also, how would that work if user logs in to multiple realms?
Also allow him to choose from UI as I mentioned above (paragraph with 
4th star)
>
> It's also very much against the whole resign of URLs to have dynamic URLs in such a way.
Maybe, I am not sure. Cookie could be one alternative and another could 
be virtual hosts. We can maybe have possibility for admins to specify 
"redirection policies" so admin can easily specify that access to 
"http://foo.keycloak.org/auth/account" would redirect users to 
"http://keycloak.org/auth/realms/foo/account" .

Admins can already put keycloak behind Apache, which provides 
possibilities to handle redirection based on various rules. I am just 
wondering if we should put something into Keycloak itself without need 
to rewrite our existing urls and give up on pluggable protocols etc.

Marek
>
>>
>> Maybe the behaviour could be somehow pluggable, so people can use
>> virtual hosts instead of cookie and access to
>> "http://foo.keycloak.org/auth/account" will use realm "foo" etc?
>>
>> Marek
>>
>> On 23.1.2015 19:00, Bill Burke wrote:
>>> We can't remove "realms" qualifier unless the admin REST interface is
>>> exposed under an entirely different WAR root context.
>>>
>>>
>>>
>>>
>>> On 1/23/2015 10:28 AM, Bill Burke wrote:
>>>> On 1/23/2015 9:36 AM, Bill Burke wrote:
>>>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
>>>>>> Our URLs are quite long, examples:
>>>>>>
>>>>>> *
>>>>>> http://localhost:8080/auth/realms/master/protocols/openid-connect/login
>>>>>> * http://localhost:8080/auth/realms/master/account
>>>>>>
>>>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
>>>>>>
>>>>>> * http://localhost:8080/auth/master/oidc/login
>>>>>> * http://localhost:8080/auth/master/account
>>>>>>
>>>>>> That would require moving everything under a realm and I guess we'd need
>>>>>> to hard-wire the protocols, but I think that should be fine.
>>>>>>
>>>>> Wouldn't work for multiple reasons.
>>>>>
>>>>> * protocols/* exists to be able to plugin different protocols (oidc,
>>>>> saml, etc.)
>>>>> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
>>>>> for both resource classes and resource locators we need both a "realms"
>>>>> and "protocols" qualifier.
>>>>>
>>>>> Its really funny you bring this up now because I've renewed my argument
>>>>> with JAX-RS JSR just 2 minutes ago!  Synchronicity!
>>>>>
>>>> Bah!  Scratch that...I think we might be able to remove "realms" so long
>>>> as we don't add any other root context wildcard resource classes.  Using
>>>> a wildcard only for "protocols" might paint us in a corner as there may
>>>> be other wildcard resources we want to add in the future.
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Mon Jan 26 05:08:23 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 05:08:23 -0500 (EST)
Subject: [keycloak-dev] Shortening URLs
In-Reply-To: <54C60C9F.6040201@redhat.com>
References: <1846266291.15791460.1422012234741.JavaMail.zimbra@redhat.com>
	<54C25C59.7030804@redhat.com> <54C268B5.9010903@redhat.com>
	<54C28C49.6010700@redhat.com> <54C6000C.3050503@redhat.com>
	<1529930941.300760.1422263080545.JavaMail.zimbra@redhat.com>
	<54C60C9F.6040201@redhat.com>
Message-ID: <1021966227.329918.1422266903112.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 10:45:03 AM
> Subject: Re: [keycloak-dev] Shortening URLs
> 
> On 26.1.2015 10:04, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Monday, January 26, 2015 9:51:24 AM
> >> Subject: Re: [keycloak-dev] Shortening URLs
> >>
> >> The main issue to address are shorter URL for services directly
> >> accessible by users, which is account mgmt and admin console, right? How
> >> about introduce aliases and add cookie scoped to '/auth' context, which
> >> will handle the name of the realm user is logged in?
> >>
> >> Some details:
> >>
> >> * User will log into realm "foo" . Keycloak will add KEYCLOAK_REALM
> >> cookie with content "foo" scoped to path "/auth" (or whatever context is
> >> auth-server deployed on)
> >>
> >> * User goes to "/auth/account" . Keycloak will read cookie and redirect
> >> user to "/auth/realms/foo/account"
> >>
> >> * User goes to "/auth/admin" . Keycloak will read cookie and redirect
> >> user to "/auth/admin/foo/console"
> >>
> >> * If user's browser is logged into 2 realms, Keycloak can display the UI
> >> page with radio buttons where user can choose his realm (Something like
> >> Google is doing for choosing your account)
> >>
> >> * If user is not logged into any realm, Keycloak can display list of all
> >> realms and user can choose? Or directly redirect user if there is just
> >> one realm available.
> > I don't like that. It will be common for a user that goes directly to
> > 'account' to not be logged-in and the user would have no clue of what
> > realm to select.
> >
> > Also, how would that work if user logs in to multiple realms?
> Also allow him to choose from UI as I mentioned above (paragraph with
> 4th star)

What if user is logged-in to one realm, but was expecting account for another? Besides, my other point still stands I don't expect a user to have any clue what a realm is.

> >
> > It's also very much against the whole resign of URLs to have dynamic URLs
> > in such a way.
> Maybe, I am not sure. Cookie could be one alternative and another could
> be virtual hosts. We can maybe have possibility for admins to specify
> "redirection policies" so admin can easily specify that access to
> "http://foo.keycloak.org/auth/account" would redirect users to
> "http://keycloak.org/auth/realms/foo/account" .
> 
> Admins can already put keycloak behind Apache, which provides
> possibilities to handle redirection based on various rules. I am just
> wondering if we should put something into Keycloak itself without need
> to rewrite our existing urls and give up on pluggable protocols etc.

A fixed alias is a better suggestion than a cookie. I really don't think it's a good idea to have a URL that redirects depending on the value of a cookie.

Still, a fixed alias seems a bit like a work-around than an actual fix

> 
> Marek
> >
> >>
> >> Maybe the behaviour could be somehow pluggable, so people can use
> >> virtual hosts instead of cookie and access to
> >> "http://foo.keycloak.org/auth/account" will use realm "foo" etc?
> >>
> >> Marek
> >>
> >> On 23.1.2015 19:00, Bill Burke wrote:
> >>> We can't remove "realms" qualifier unless the admin REST interface is
> >>> exposed under an entirely different WAR root context.
> >>>
> >>>
> >>>
> >>>
> >>> On 1/23/2015 10:28 AM, Bill Burke wrote:
> >>>> On 1/23/2015 9:36 AM, Bill Burke wrote:
> >>>>> On 1/23/2015 6:23 AM, Stian Thorgersen wrote:
> >>>>>> Our URLs are quite long, examples:
> >>>>>>
> >>>>>> *
> >>>>>> http://localhost:8080/auth/realms/master/protocols/openid-connect/login
> >>>>>> * http://localhost:8080/auth/realms/master/account
> >>>>>>
> >>>>>> We could remove the 'realms' part and 'protocols' parts couldn't we?
> >>>>>>
> >>>>>> * http://localhost:8080/auth/master/oidc/login
> >>>>>> * http://localhost:8080/auth/master/account
> >>>>>>
> >>>>>> That would require moving everything under a realm and I guess we'd
> >>>>>> need
> >>>>>> to hard-wire the protocols, but I think that should be fine.
> >>>>>>
> >>>>> Wouldn't work for multiple reasons.
> >>>>>
> >>>>> * protocols/* exists to be able to plugin different protocols (oidc,
> >>>>> saml, etc.)
> >>>>> * Because of the crappy way JAX-RS dispatch algorithm handles wildcards
> >>>>> for both resource classes and resource locators we need both a "realms"
> >>>>> and "protocols" qualifier.
> >>>>>
> >>>>> Its really funny you bring this up now because I've renewed my argument
> >>>>> with JAX-RS JSR just 2 minutes ago!  Synchronicity!
> >>>>>
> >>>> Bah!  Scratch that...I think we might be able to remove "realms" so long
> >>>> as we don't add any other root context wildcard resource classes.  Using
> >>>> a wildcard only for "protocols" might paint us in a corner as there may
> >>>> be other wildcard resources we want to add in the future.
> >>>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From psilva at redhat.com  Mon Jan 26 06:54:38 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 26 Jan 2015 06:54:38 -0500 (EST)
Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
 provider
In-Reply-To: <1086360506.239290.1422256694761.JavaMail.zimbra@redhat.com>
References: <275977940.14344560.1422040999890.JavaMail.zimbra@redhat.com>
	<1086360506.239290.1422256694761.JavaMail.zimbra@redhat.com>
Message-ID: <236041000.245831.1422273278444.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, January 26, 2015 5:18:14 AM
> Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
> 
> Can you elaborate a bit more on the idea? At first glance to me it seems like
> we'd use one field for two quite different purposes. Level of assurance is
> abstract (level 0, 1, 2), while authentication mechanism is more concrete
> (idp-a, password, totp). I think an application might want to request
> level-1, but not care about mechanism used, while another application would
> want to select idp-a, but not care about the level of assurance.

I understand your point. You are basically talking about "acr" and "amr" fields of id_token.

After reading a little bit more about the meaning of both fields, I realized that acr provides more meaning than amr. The reason is that you would prefer a "context" than rely on specific authentication mechanisms in order to do access decisions. For instance, SAML provides something similar to amr and for some people that is one of the SAML specs mistakes. And there are discussions on OIDC mailing lists about the real value of "amr".

IMO, makes much more sense to rely on the context used to authenticate the user than on an individual (or multiple) authentication mechanism. You can use the context for that in a more meaningful (and abstract) way. In the case we are discussing, users can specify that an "authentication context" is related with trusting identities from an external IdP.

In the future, we may even let users create their own "authentication context" by chaining authentication mechanisms. For instance, password + otp. IMO, is much better to use a single value like acme-loa-1, which means password + otp, than check for individual mechanisms.

Regarding the value, I think we can use anything we want as along as all parties agree on the values being used.

> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, January 23, 2015 8:23:19 PM
> > Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > provider
> > 
> > Hi,
> > 
> >     KEYCLOAK-996 is about allowing clients to select an existing identity
> >     provider when sending an authentication request to the server.
> >     Initially, this is all about passing the IdP id and automatically
> >     redirect the user to its login page. Without even show KC's login page.
> > 
> >     IMO instead of using an "idp_hint", like proposed in that JIRA, we may
> >     start using the "acr_values" parameter as defined by OIDC specs. I
> >     think
> >     this parameter better fits the purpose and will allow us to support
> >     LoAs
> >     in the future as well.
> > 
> >     The acr value in this case would be something like "idp-X", where X is
> >     the id of the identity provider.
> > 
> >     What do you think ?
> > 
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From bburke at redhat.com  Mon Jan 26 07:17:21 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jan 2015 07:17:21 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com> <54C2D0E5.3030702@redhat.com>
	<54C38976.2060807@redhat.com> <54C5A07C.1050102@redhat.com>
	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
Message-ID: <54C63051.4070608@redhat.com>



On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, January 26, 2015 3:03:40 AM
>> Subject: Re: [keycloak-dev] aggregate modules
>>
>>
>>
>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>> Ran into a wall:
>>>>
>>>> I couldn't have an aggregate module.  service imports didn't seem to
>>>> work so I had to create a dependency for everything within
>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
>>>> errors in my module defintions.
>>> In Brno I can ask David about this.  Can you post your
>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>
>>>> I'm at a wall.  I can't get the JPA connections to find the Hibernate
>>>> provider.  I"m not sure if it can't find persistence.xml or hibernate or
>>>> what.  Tried importing hibernate in various places to no avail.  Error
>>>> Message isn't very helpful either:
>>>>
>>>> javax.persistence.PersistenceException: No Persistence provider for
>>>> EntityManager named keycloak-default
>>> Can you give me a scaled down reproducer for this one?  I can ask around
>>> and see if anyone knows a solution.
>>
>> I think this is another service import problem.
>
> Loading JPA in this way will work, but it's a bit of a PITA. META-INF/persistence.xml isn't exported/imported by default, see https://developer.jboss.org/message/828881#828881
>
> If you're fed up and commit your stuff I can take a look. I've gone done this in the past so should be able to get it to work again.
>

Zoinks...I'll try importing META-INF.

Are we sure we want users dealing with JBoss Modules?



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

From stian at redhat.com  Mon Jan 26 07:26:10 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 07:26:10 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C63051.4070608@redhat.com>
References: <54C15A15.50108@redhat.com> <54C2D0E5.3030702@redhat.com>
	<54C38976.2060807@redhat.com> <54C5A07C.1050102@redhat.com>
	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
	<54C63051.4070608@redhat.com>
Message-ID: <1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 1:17:21 PM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> 
> 
> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, January 26, 2015 3:03:40 AM
> >> Subject: Re: [keycloak-dev] aggregate modules
> >>
> >>
> >>
> >> On 1/24/2015 7:00 AM, Stan Silvert wrote:
> >>> On 1/23/2015 5:53 PM, Bill Burke wrote:
> >>>> Ran into a wall:
> >>>>
> >>>> I couldn't have an aggregate module.  service imports didn't seem to
> >>>> work so I had to create a dependency for everything within
> >>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
> >>>> errors in my module defintions.
> >>> In Brno I can ask David about this.  Can you post your
> >>> jboss-deployment-structure.xml and your aggregate module.xml?
> >>>>
> >>>> I'm at a wall.  I can't get the JPA connections to find the Hibernate
> >>>> provider.  I"m not sure if it can't find persistence.xml or hibernate or
> >>>> what.  Tried importing hibernate in various places to no avail.  Error
> >>>> Message isn't very helpful either:
> >>>>
> >>>> javax.persistence.PersistenceException: No Persistence provider for
> >>>> EntityManager named keycloak-default
> >>> Can you give me a scaled down reproducer for this one?  I can ask around
> >>> and see if anyone knows a solution.
> >>
> >> I think this is another service import problem.
> >
> > Loading JPA in this way will work, but it's a bit of a PITA.
> > META-INF/persistence.xml isn't exported/imported by default, see
> > https://developer.jboss.org/message/828881#828881
> >
> > If you're fed up and commit your stuff I can take a look. I've gone done
> > this in the past so should be able to get it to work again.
> >
> 
> Zoinks...I'll try importing META-INF.
> 
> Are we sure we want users dealing with JBoss Modules?

Yes ;)

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

From gerbermichi at me.com  Mon Jan 26 07:37:53 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 26 Jan 2015 12:37:53 +0000 (GMT)
Subject: [keycloak-dev] Looking for a workaround...
Message-ID: <f7d46a79-79ed-4a1a-b33b-3cc3c41d3eed@me.com>

Hi all,

I receive a lot of bug reports from our test team because of the following two issues:
- Reset password leads to 400 Bad Request (https://issues.jboss.org/browse/KEYCLOAK-1014)
-?Login attempt after "Login user action lifespan" leads to "Invalid username or password." (https://issues.jboss.org/browse/KEYCLOAK-1015)

Do you have any good ideas for a workaround?

Best
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150126/123b78d1/attachment.html 

From stian at redhat.com  Mon Jan 26 07:54:46 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 07:54:46 -0500 (EST)
Subject: [keycloak-dev] Looking for a workaround...
In-Reply-To: <f7d46a79-79ed-4a1a-b33b-3cc3c41d3eed@me.com>
References: <f7d46a79-79ed-4a1a-b33b-3cc3c41d3eed@me.com>
Message-ID: <2076374932.396944.1422276886986.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 1:37:53 PM
> Subject: [keycloak-dev] Looking for a workaround...
> 
> Hi all,
> 
> I receive a lot of bug reports from our test team because of the following
> two issues:
> - Reset password leads to 400 Bad Request (
> https://issues.jboss.org/browse/KEYCLOAK-1014 )

This is a tricky one - we can't ignore the state variable as that would make it vulnerable.

We could probably come up with an alternative way to generate and verify state variable though. Could be a HMAC for example.

> - Login attempt after "Login user action lifespan" leads to "Invalid username
> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )

I agree that the error message is not very good, but I disagree with removing the expiration. Why not increase it to say 30 min? That's probably a more sensible timeout for reset password as well.

> 
> Do you have any good ideas for a workaround?
> 
> Best
> Michael
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Mon Jan 26 08:07:09 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 08:07:09 -0500 (EST)
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <2125881691.401791.1422277369055.JavaMail.zimbra@redhat.com>
Message-ID: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>

Someone reported https://issues.jboss.org/browse/KEYCLOAK-1014. In summary if you click on reset password, close the browser, then click the link in the email to recover password the state cookie won't be set.

Some suggestions on how to solve this:

* Store state variable in non-session cookie (with some sensible expiration 24h?)
* Generate/verify state using HMAC on the server-side instead of using uuid
* Improve error message on client side if state is not correct, basically asking user to re-login - can this be easily implemented in the app itself with the adapter today?

From stian at redhat.com  Mon Jan 26 08:18:24 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 08:18:24 -0500 (EST)
Subject: [keycloak-dev] Intermittent test failures in
 SyncProvidersTest.testLDAPSync and
 CookieTokenStoreAdapterTest.testTokenInCookieRefresh
In-Reply-To: <353744271.405782.1422277764796.JavaMail.zimbra@redhat.com>
Message-ID: <1926416125.409746.1422278304485.JavaMail.zimbra@redhat.com>

SyncProvidersTest.testLDAPSync and CookieTokenStoreAdapterTest.testTokenInCookieRefresh are failing for me once in a while. Also fails on Jenkins.

Failed tests: 
  SyncProvidersTest.testLDAPSync:142->assertUserImported:191 expected:<User5FN[Updated]> but was:<User5FN[]>
  CookieTokenStoreAdapterTest.testTokenInCookieRefresh:110 Values should be different. Actual: eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJzdWJqZWN0IjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiZ2l2ZW5fbmFtZSI6IkJpbGwiLCJmYW1pbHlfbmFtZSI6IkJ1cmtlIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsImp0aSI6IjBlMWI0Mzc4LWVjMGQtNDIzMS04NmU4LWI1YjNkYjA0NWNkNiIsImV4cCI6MTQyMjI2MzY0NCwibmJmIjowLCJpYXQiOjE0MjIyNjM2NDEsImlzcyI6ImRlbW8iLCJhdWQiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiYXpwIjoiY3VzdG9tZXItY29va2llLXBvcnRhbCIsInNlc3Npb25fc3RhdGUiOiIwNjBmM2FjYy1jZDkxLTQwZTUtOTEzOS1lODRlMTNiMmY3MDkiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cDovL2xvY2FsaG9zdDo4MDgxIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCJdfX19.Zzdkcx-LbBPtX_xCGjxBT2d8VOzwSP8i8XdiSsfpOotPGN0D7aiehb3QrvXjYcFOMgkutWNMfZxeNcJ9iN3kxcV7IA6AYchVPLo-WX1fUmRiUbpghophQA5pjbxB3Riqn5W0G6A_zFvkPRPQohXeiO_Wq0Ao_mBQGvhZg1RN0u0 at eyJhbGciOiJSUzI1NiJ9.eyJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJnaXZlbl9uYW1lIjoiQmlsbCIsImZhbWlseV9uYW1lIjoiQnVya2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJiYnVya2VAcmVkaGF0LmNvbSIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwianRpIjoiNDk0OGYzNjktMGJmOS00MTA0LTg3ZjUtZGIzYWExZGE0Nzg0IiwiZXhwIjoxNDIyMjYzNjQ0LCJuYmYiOjAsImlhdCI6MTQyMjI2MzY0MSwiaXNzIjoiZGVtbyIsImF1ZCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJhenAiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIn0.m6n2f2uJUPapm3L73PgtB0Lqyqi7dZgzI0G_9-X7G9DUq0dB-h5GJVezfLmVlESjuw2K7Jn3urEwjD_gTShecEDGnJeSfi-EYRbBQvolcATapT8wN7-LabP95MdIH3ustnjQExhXNYxGG0QlA1c4oA9OebLzG-SX314U5Ha6-OQ@eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJlN2FkMzEyNC1lNzk0LTRiMDEtYTAxOS1mN2NjODQzNmZiYTIiLCJleHAiOjE0MjIyNjU0NDEsIm5iZiI6MCwiaWF0IjoxNDIyMjYzNjQxLCJpc3MiOiJkZW1vIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwidHlwIjoiUkVGUkVTSCIsImF6cCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzZXNzaW9uX3N0YXRlIjoiMDYwZjNhY2MtY2Q5MS00MGU1LTkxMzktZTg0ZTEzYjJmNzA5IiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Il19fX0.prz4dbCq66DqnpAudzfcghuYje30D96MSuVWqk9pIVVmx5-4qMIDCfoS3hbeJpV98OYlRHSpKBQI-FTTWEm-mWKBY30SAzutbwbf7nXG3TuF5-lId3tNsc_tA72XW9HoEAW9_AVA8_w4L51D7D_x7RnFiRa7k2WDaRjlrF9nBQk


Anyone know why these are failing?


From stian at redhat.com  Mon Jan 26 08:23:43 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 08:23:43 -0500 (EST)
Subject: [keycloak-dev] Looking for a workaround...
In-Reply-To: <fe346a5a-e042-4138-aa1c-29b472b75f1a@me.com>
References: <fe346a5a-e042-4138-aa1c-29b472b75f1a@me.com>
Message-ID: <6026216.411672.1422278623015.JavaMail.zimbra@redhat.com>

Adding list back to thread, please remember to reply to all




----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Sent: Monday, January 26, 2015 2:10:59 PM
> Subject: Re: [keycloak-dev] Looking for a workaround...
> 
> 
> 
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 1:37:53 PM
> Subject: [keycloak-dev] Looking for a workaround...
> Hi all,
> I receive a lot of bug reports from our test team because of the following
> two issues:
> - Reset password leads to 400 Bad Request (
> https://issues.jboss.org/browse/KEYCLOAK-1014 )
> 
> This is a tricky one - we can't ignore the state variable as that would make
> it vulnerable.
> 
> We could probably come up with an alternative way to generate and verify
> state variable though. Could be a HMAC for example.
> So you would remove the state cookie?

It could potentially be a solution - I started a separate thread on keycloak-dev to discuss this.

> 
> 
> - Login attempt after "Login user action lifespan" leads to "Invalid username
> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )
> 
> I agree that the error message is not very good, but I disagree with removing
> the expiration. Why not increase it to say 30 min? That's probably a more
> sensible timeout for reset password as well.
> I prefer an expiration of 5 min for the password update process, but thats a
> bit short for the authentication or password reset process.
> I think the best solution would be different expiration times for the
> different processes, wouldn't it?

Maybe - we do try to keep configuration options to a minimum as these introduce complexity as well as potentials for bug/security issues.

> 
> 
> Do you have any good ideas for a workaround?
> Best
> Michael
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Mon Jan 26 08:27:30 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jan 2015 08:27:30 -0500
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>
References: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>
Message-ID: <54C640C2.1080000@redhat.com>

Wouldn't this work?

1) store "state" of state cookie in user session.
2) embed user session and state of state cookie in URL

Of course this screws up your "shorter URL" crusade.

On 1/26/2015 8:07 AM, Stian Thorgersen wrote:
> Someone reported https://issues.jboss.org/browse/KEYCLOAK-1014. In summary if you click on reset password, close the browser, then click the link in the email to recover password the state cookie won't be set.
>
> Some suggestions on how to solve this:
>
> * Store state variable in non-session cookie (with some sensible expiration 24h?)
> * Generate/verify state using HMAC on the server-side instead of using uuid
> * Improve error message on client side if state is not correct, basically asking user to re-login - can this be easily implemented in the app itself with the adapter today?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Mon Jan 26 08:35:01 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 08:35:01 -0500 (EST)
Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
 provider
In-Reply-To: <236041000.245831.1422273278444.JavaMail.zimbra@redhat.com>
References: <275977940.14344560.1422040999890.JavaMail.zimbra@redhat.com>
	<1086360506.239290.1422256694761.JavaMail.zimbra@redhat.com>
	<236041000.245831.1422273278444.JavaMail.zimbra@redhat.com>
Message-ID: <1137021729.416125.1422279301099.JavaMail.zimbra@redhat.com>

Reading the spec, although they don't exactly give much detail on this, but my understanding is:

* acr - abstract level of assurance, exactly how the levels are defined I don't know, but I would imagine they'd have values 1-10 or somthing. You could then define what's required for each value. For example 0 is just authenticated somehow, 1 is either password+totp or my-corp-idp
* amr - is a concrete list of mechanisms used, so examples would be 'totp password' or 'my-corp-id'

>From your previous email I'm a bit unsure if you're still proposing to use acr_values or not, but to me it doesn't make sense have ?acr_values=my-corp-idp. If there was an amr_values param that would make more sense.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, January 26, 2015 12:54:38 PM
> Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Monday, January 26, 2015 5:18:14 AM
> > Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > provider
> > 
> > Can you elaborate a bit more on the idea? At first glance to me it seems
> > like
> > we'd use one field for two quite different purposes. Level of assurance is
> > abstract (level 0, 1, 2), while authentication mechanism is more concrete
> > (idp-a, password, totp). I think an application might want to request
> > level-1, but not care about mechanism used, while another application would
> > want to select idp-a, but not care about the level of assurance.
> 
> I understand your point. You are basically talking about "acr" and "amr"
> fields of id_token.
> 
> After reading a little bit more about the meaning of both fields, I realized
> that acr provides more meaning than amr. The reason is that you would prefer
> a "context" than rely on specific authentication mechanisms in order to do
> access decisions. For instance, SAML provides something similar to amr and
> for some people that is one of the SAML specs mistakes. And there are
> discussions on OIDC mailing lists about the real value of "amr".
> 
> IMO, makes much more sense to rely on the context used to authenticate the
> user than on an individual (or multiple) authentication mechanism. You can
> use the context for that in a more meaningful (and abstract) way. In the
> case we are discussing, users can specify that an "authentication context"
> is related with trusting identities from an external IdP.
> 
> In the future, we may even let users create their own "authentication
> context" by chaining authentication mechanisms. For instance, password +
> otp. IMO, is much better to use a single value like acme-loa-1, which means
> password + otp, than check for individual mechanisms.
> 
> Regarding the value, I think we can use anything we want as along as all
> parties agree on the values being used.
> 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, January 23, 2015 8:23:19 PM
> > > Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > > provider
> > > 
> > > Hi,
> > > 
> > >     KEYCLOAK-996 is about allowing clients to select an existing identity
> > >     provider when sending an authentication request to the server.
> > >     Initially, this is all about passing the IdP id and automatically
> > >     redirect the user to its login page. Without even show KC's login
> > >     page.
> > > 
> > >     IMO instead of using an "idp_hint", like proposed in that JIRA, we
> > >     may
> > >     start using the "acr_values" parameter as defined by OIDC specs. I
> > >     think
> > >     this parameter better fits the purpose and will allow us to support
> > >     LoAs
> > >     in the future as well.
> > > 
> > >     The acr value in this case would be something like "idp-X", where X
> > >     is
> > >     the id of the identity provider.
> > > 
> > >     What do you think ?
> > > 
> > > Regards.
> > > Pedro Igor
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

From stian at redhat.com  Mon Jan 26 08:45:17 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 26 Jan 2015 08:45:17 -0500 (EST)
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <54C640C2.1080000@redhat.com>
References: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>
	<54C640C2.1080000@redhat.com>
Message-ID: <1347626282.420665.1422279917422.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 2:27:30 PM
> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> 
> Wouldn't this work?
> 
> 1) store "state" of state cookie in user session.
> 2) embed user session and state of state cookie in URL
> 
> Of course this screws up your "shorter URL" crusade.

I'm not following - the problem isn't remembering the state variable in Keycloak, that's already sorted as we already store all the query params passed by the client in the client session (state, redirect_uri, etc). The problem is storing it on the adapter side.

> 
> On 1/26/2015 8:07 AM, Stian Thorgersen wrote:
> > Someone reported https://issues.jboss.org/browse/KEYCLOAK-1014. In summary
> > if you click on reset password, close the browser, then click the link in
> > the email to recover password the state cookie won't be set.
> >
> > Some suggestions on how to solve this:
> >
> > * Store state variable in non-session cookie (with some sensible expiration
> > 24h?)
> > * Generate/verify state using HMAC on the server-side instead of using uuid
> > * Improve error message on client side if state is not correct, basically
> > asking user to re-login - can this be easily implemented in the app itself
> > with the adapter today?
> > _______________________________________________
> > 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  Mon Jan 26 09:33:48 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 26 Jan 2015 09:33:48 -0500 (EST)
Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
 provider
In-Reply-To: <1137021729.416125.1422279301099.JavaMail.zimbra@redhat.com>
References: <275977940.14344560.1422040999890.JavaMail.zimbra@redhat.com>
	<1086360506.239290.1422256694761.JavaMail.zimbra@redhat.com>
	<236041000.245831.1422273278444.JavaMail.zimbra@redhat.com>
	<1137021729.416125.1422279301099.JavaMail.zimbra@redhat.com>
Message-ID: <1019066154.419144.1422282828261.JavaMail.zimbra@redhat.com>

I'm still proposing acr_values, which is related with the acr claim within the id_token. 

Regarding the value, my understanding is that you are not tied with numeric values, but you can have anything (specs says URIs) as long as both parties agree on the values in use.

For me, authentication context is all about how the user was authenticated. And use that info to make access decision. For instance, when authenticating against a trusted IdP I don't care how the user is authenticated. What I care is that the IdP really authenticated the user and I trust it. Based on that, my app may protect (or not) specific resources based on the context the user was authenticated.

I don't think amr_values makes sense to request specific mechanisms. As I said, acr is enough to specify one or multiple mechanisms in a more meaningful (and abstract) way without rely on a specific mech. Something like an alias.

Suppose my company defines that acme-authc-1 is password-based authc. But new policies were defined and require that acme-authc-1 should be passord + otp. Apps don't have to change if they rely on this context. Now, if you use rely on specific mechanisms, your apps should check each of them. And in this case, they would need to change in order to also consider the otp mech.

Beside that, that opens a window to provide useful features in KeyCloak (in the future :)) regarding all that.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Monday, January 26, 2015 11:35:01 AM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider

Reading the spec, although they don't exactly give much detail on this, but my understanding is:

* acr - abstract level of assurance, exactly how the levels are defined I don't know, but I would imagine they'd have values 1-10 or somthing. You could then define what's required for each value. For example 0 is just authenticated somehow, 1 is either password+totp or my-corp-idp
* amr - is a concrete list of mechanisms used, so examples would be 'totp password' or 'my-corp-id'

>From your previous email I'm a bit unsure if you're still proposing to use acr_values or not, but to me it doesn't make sense have ?acr_values=my-corp-idp. If there was an amr_values param that would make more sense.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, January 26, 2015 12:54:38 PM
> Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Monday, January 26, 2015 5:18:14 AM
> > Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > provider
> > 
> > Can you elaborate a bit more on the idea? At first glance to me it seems
> > like
> > we'd use one field for two quite different purposes. Level of assurance is
> > abstract (level 0, 1, 2), while authentication mechanism is more concrete
> > (idp-a, password, totp). I think an application might want to request
> > level-1, but not care about mechanism used, while another application would
> > want to select idp-a, but not care about the level of assurance.
> 
> I understand your point. You are basically talking about "acr" and "amr"
> fields of id_token.
> 
> After reading a little bit more about the meaning of both fields, I realized
> that acr provides more meaning than amr. The reason is that you would prefer
> a "context" than rely on specific authentication mechanisms in order to do
> access decisions. For instance, SAML provides something similar to amr and
> for some people that is one of the SAML specs mistakes. And there are
> discussions on OIDC mailing lists about the real value of "amr".
> 
> IMO, makes much more sense to rely on the context used to authenticate the
> user than on an individual (or multiple) authentication mechanism. You can
> use the context for that in a more meaningful (and abstract) way. In the
> case we are discussing, users can specify that an "authentication context"
> is related with trusting identities from an external IdP.
> 
> In the future, we may even let users create their own "authentication
> context" by chaining authentication mechanisms. For instance, password +
> otp. IMO, is much better to use a single value like acme-loa-1, which means
> password + otp, than check for individual mechanisms.
> 
> Regarding the value, I think we can use anything we want as along as all
> parties agree on the values being used.
> 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, January 23, 2015 8:23:19 PM
> > > Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > > provider
> > > 
> > > Hi,
> > > 
> > >     KEYCLOAK-996 is about allowing clients to select an existing identity
> > >     provider when sending an authentication request to the server.
> > >     Initially, this is all about passing the IdP id and automatically
> > >     redirect the user to its login page. Without even show KC's login
> > >     page.
> > > 
> > >     IMO instead of using an "idp_hint", like proposed in that JIRA, we
> > >     may
> > >     start using the "acr_values" parameter as defined by OIDC specs. I
> > >     think
> > >     this parameter better fits the purpose and will allow us to support
> > >     LoAs
> > >     in the future as well.
> > > 
> > >     The acr value in this case would be something like "idp-X", where X
> > >     is
> > >     the id of the identity provider.
> > > 
> > >     What do you think ?
> > > 
> > > Regards.
> > > Pedro Igor
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

From mposolda at redhat.com  Mon Jan 26 09:48:57 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 26 Jan 2015 15:48:57 +0100
Subject: [keycloak-dev] Intermittent test failures in
 SyncProvidersTest.testLDAPSync and
 CookieTokenStoreAdapterTest.testTokenInCookieRefresh
In-Reply-To: <1926416125.409746.1422278304485.JavaMail.zimbra@redhat.com>
References: <1926416125.409746.1422278304485.JavaMail.zimbra@redhat.com>
Message-ID: <54C653D9.3010909@redhat.com>

I will try to take a look at those.

Marek

On 26.1.2015 14:18, Stian Thorgersen wrote:
> SyncProvidersTest.testLDAPSync and CookieTokenStoreAdapterTest.testTokenInCookieRefresh are failing for me once in a while. Also fails on Jenkins.
>
> Failed tests:
>    SyncProvidersTest.testLDAPSync:142->assertUserImported:191 expected:<User5FN[Updated]> but was:<User5FN[]>
>    CookieTokenStoreAdapterTest.testTokenInCookieRefresh:110 Values should be different. Actual: eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJzdWJqZWN0IjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiZ2l2ZW5fbmFtZSI6IkJpbGwiLCJmYW1pbHlfbmFtZSI6IkJ1cmtlIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsImp0aSI6IjBlMWI0Mzc4LWVjMGQtNDIzMS04NmU4LWI1YjNkYjA0NWNkNiIsImV4cCI6MTQyMjI2MzY0NCwibmJmIjowLCJpYXQiOjE0MjIyNjM2NDEsImlzcyI6ImRlbW8iLCJhdWQiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiYXpwIjoiY3VzdG9tZXItY29va2llLXBvcnRhbCIsInNlc3Npb25fc3RhdGUiOiIwNjBmM2FjYy1jZDkxLTQwZTUtOTEzOS1lODRlMTNiMmY3MDkiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cDovL2xvY2FsaG9zdDo4MDgxIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCJdfX19.Zzdkcx-L!
>   bBPtX_xCGjxBT2d8VOzwSP8i8XdiSsfpOotPGN0D7aiehb3QrvXjYcFOMgkutWNMfZxeNcJ9iN3kxcV7IA6AYchVPLo-WX1fUmRiUbpghophQA5pjbxB3Riqn5W0G6A_zFvkPRPQohXeiO_Wq0Ao_mBQGvhZg1RN0u0 at eyJhbGciOiJSUzI1NiJ9.eyJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJnaXZlbl9uYW1lIjoiQmlsbCIsImZhbWlseV9uYW1lIjoiQnVya2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJiYnVya2VAcmVkaGF0LmNvbSIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwianRpIjoiNDk0OGYzNjktMGJmOS00MTA0LTg3ZjUtZGIzYWExZGE0Nzg0IiwiZXhwIjoxNDIyMjYzNjQ0LCJuYmYiOjAsImlhdCI6MTQyMjI2MzY0MSwiaXNzIjoiZGVtbyIsImF1ZCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJhenAiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIn0.m6n2f2uJUPapm3L73PgtB0Lqyqi7dZgzI0G_9-X7G9DUq0dB-h5GJVezfLmVlESjuw2K7Jn3urEwjD_gTShecEDGnJeSfi-EYRbBQvolcATapT8wN7-LabP95MdIH3ustnjQExhXNYxGG0QlA1c4oA9OebLzG-SX314U5Ha6-OQ@eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJlN2FkMzEyNC1lNzk0LTRiMDEtYTAxOS1mN2NjODQzNmZiYTIiLCJleHAiOjE0MjIyNjU0NDEsIm5iZiI6MCwiaWF0IjoxNDIyMjYzNjQxLCJpc3MiOi!
>   JkZW1vIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcy!
>   NTY1Iiwi
> dHlwIjoiUkVGUkVTSCIsImF6cCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzZXNzaW9uX3N0YXRlIjoiMDYwZjNhY2MtY2Q5MS00MGU1LTkxMzktZTg0ZTEzYjJmNzA5IiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Il19fX0.prz4dbCq66DqnpAudzfcghuYje30D96MSuVWqk9pIVVmx5-4qMIDCfoS3hbeJpV98OYlRHSpKBQI-FTTWEm-mWKBY30SAzutbwbf7nXG3TuF5-lId3tNsc_tA72XW9HoEAW9_AVA8_w4L51D7D_x7RnFiRa7k2WDaRjlrF9nBQk
>
>
> Anyone know why these are failing?
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




From psilva at redhat.com  Mon Jan 26 09:56:28 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 26 Jan 2015 09:56:28 -0500 (EST)
Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
 provider
In-Reply-To: <1019066154.419144.1422282828261.JavaMail.zimbra@redhat.com>
References: <275977940.14344560.1422040999890.JavaMail.zimbra@redhat.com>
	<1086360506.239290.1422256694761.JavaMail.zimbra@redhat.com>
	<236041000.245831.1422273278444.JavaMail.zimbra@redhat.com>
	<1137021729.416125.1422279301099.JavaMail.zimbra@redhat.com>
	<1019066154.419144.1422282828261.JavaMail.zimbra@redhat.com>
Message-ID: <555010082.494348.1422284188985.JavaMail.zimbra@redhat.com>

Btw, acr can tell more than just authc mechs. It may mean specific characteristic of the session itself. For instance, token lifetime, etc.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Monday, January 26, 2015 12:33:48 PM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider

I'm still proposing acr_values, which is related with the acr claim within the id_token. 

Regarding the value, my understanding is that you are not tied with numeric values, but you can have anything (specs says URIs) as long as both parties agree on the values in use.

For me, authentication context is all about how the user was authenticated. And use that info to make access decision. For instance, when authenticating against a trusted IdP I don't care how the user is authenticated. What I care is that the IdP really authenticated the user and I trust it. Based on that, my app may protect (or not) specific resources based on the context the user was authenticated.

I don't think amr_values makes sense to request specific mechanisms. As I said, acr is enough to specify one or multiple mechanisms in a more meaningful (and abstract) way without rely on a specific mech. Something like an alias.

Suppose my company defines that acme-authc-1 is password-based authc. But new policies were defined and require that acme-authc-1 should be passord + otp. Apps don't have to change if they rely on this context. Now, if you use rely on specific mechanisms, your apps should check each of them. And in this case, they would need to change in order to also consider the otp mech.

Beside that, that opens a window to provide useful features in KeyCloak (in the future :)) regarding all that.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Monday, January 26, 2015 11:35:01 AM
Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider

Reading the spec, although they don't exactly give much detail on this, but my understanding is:

* acr - abstract level of assurance, exactly how the levels are defined I don't know, but I would imagine they'd have values 1-10 or somthing. You could then define what's required for each value. For example 0 is just authenticated somehow, 1 is either password+totp or my-corp-idp
* amr - is a concrete list of mechanisms used, so examples would be 'totp password' or 'my-corp-id'

>From your previous email I'm a bit unsure if you're still proposing to use acr_values or not, but to me it doesn't make sense have ?acr_values=my-corp-idp. If there was an amr_values param that would make more sense.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, January 26, 2015 12:54:38 PM
> Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select provider
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Monday, January 26, 2015 5:18:14 AM
> > Subject: Re: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > provider
> > 
> > Can you elaborate a bit more on the idea? At first glance to me it seems
> > like
> > we'd use one field for two quite different purposes. Level of assurance is
> > abstract (level 0, 1, 2), while authentication mechanism is more concrete
> > (idp-a, password, totp). I think an application might want to request
> > level-1, but not care about mechanism used, while another application would
> > want to select idp-a, but not care about the level of assurance.
> 
> I understand your point. You are basically talking about "acr" and "amr"
> fields of id_token.
> 
> After reading a little bit more about the meaning of both fields, I realized
> that acr provides more meaning than amr. The reason is that you would prefer
> a "context" than rely on specific authentication mechanisms in order to do
> access decisions. For instance, SAML provides something similar to amr and
> for some people that is one of the SAML specs mistakes. And there are
> discussions on OIDC mailing lists about the real value of "amr".
> 
> IMO, makes much more sense to rely on the context used to authenticate the
> user than on an individual (or multiple) authentication mechanism. You can
> use the context for that in a more meaningful (and abstract) way. In the
> case we are discussing, users can specify that an "authentication context"
> is related with trusting identities from an external IdP.
> 
> In the future, we may even let users create their own "authentication
> context" by chaining authentication mechanisms. For instance, password +
> otp. IMO, is much better to use a single value like acme-loa-1, which means
> password + otp, than check for individual mechanisms.
> 
> Regarding the value, I think we can use anything we want as along as all
> parties agree on the values being used.
> 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Friday, January 23, 2015 8:23:19 PM
> > > Subject: [keycloak-dev] [KEYCLOAK-996] - Allow application to select
> > > provider
> > > 
> > > Hi,
> > > 
> > >     KEYCLOAK-996 is about allowing clients to select an existing identity
> > >     provider when sending an authentication request to the server.
> > >     Initially, this is all about passing the IdP id and automatically
> > >     redirect the user to its login page. Without even show KC's login
> > >     page.
> > > 
> > >     IMO instead of using an "idp_hint", like proposed in that JIRA, we
> > >     may
> > >     start using the "acr_values" parameter as defined by OIDC specs. I
> > >     think
> > >     this parameter better fits the purpose and will allow us to support
> > >     LoAs
> > >     in the future as well.
> > > 
> > >     The acr value in this case would be something like "idp-X", where X
> > >     is
> > >     the id of the identity provider.
> > > 
> > >     What do you think ?
> > > 
> > > Regards.
> > > Pedro Igor
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From gerbermichi at me.com  Mon Jan 26 10:23:49 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 26 Jan 2015 15:23:49 +0000 (GMT)
Subject: [keycloak-dev] Looking for a workaround...
Message-ID: <ef0cd52d-966b-45c8-bb13-cf99cc9c5267@me.com>

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

And it doesn't make sense to have a different conffiguration for every one...
But maybe we can group it into different groups??

>
>
>> Do you have any good ideas for a workaround?
>> Best
>> Michael
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>>  
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150126/75c4fc1b/attachment-0001.html 

From bburke at redhat.com  Mon Jan 26 10:54:35 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jan 2015 10:54:35 -0500
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <1347626282.420665.1422279917422.JavaMail.zimbra@redhat.com>
References: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>
	<54C640C2.1080000@redhat.com>
	<1347626282.420665.1422279917422.JavaMail.zimbra@redhat.com>
Message-ID: <54C6633B.3080106@redhat.com>



On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, January 26, 2015 2:27:30 PM
>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>
>> Wouldn't this work?
>>
>> 1) store "state" of state cookie in user session.
>> 2) embed user session and state of state cookie in URL
>>
>> Of course this screws up your "shorter URL" crusade.
>
> I'm not following - the problem isn't remembering the state variable in Keycloak, that's already sorted as we already store all the query params passed by the client in the client session (state, redirect_uri, etc). The problem is storing it on the adapter side.
>

I think I get it...


1. Send email
2. Close browser
3. Open browser
4. Click email link
5. Reset password
6. Redirect back to app
7. App barfs because of state cookie


Persistent state cookie sounds like cleanest and simplest solution. I 
just worry we'll introduce different bugs, or if we're opening up some 
kind of security hole.  Maybe I'm just paranoid.

Another possibility:

* Maybe set a auth server session cookie.  If that cookie isn't set, 
just redirect to a auth server page that says "Password was reset" and 
don't redirect back to the application.



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

From mposolda at redhat.com  Mon Jan 26 11:28:29 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 26 Jan 2015 17:28:29 +0100
Subject: [keycloak-dev] Intermittent test failures in
 SyncProvidersTest.testLDAPSync and
 CookieTokenStoreAdapterTest.testTokenInCookieRefresh
In-Reply-To: <54C653D9.3010909@redhat.com>
References: <1926416125.409746.1422278304485.JavaMail.zimbra@redhat.com>
	<54C653D9.3010909@redhat.com>
Message-ID: <54C66B2D.1050008@redhat.com>

I think I have a fix (despite the fact I did not simulate test failure 
on my laptop ;-)

Commited to master and 1.1.x branches.

It's caused by uncleared offset on org.keycloak.util.Time, which is 
static and shared per the JVM for all tests. I wonder if we should put 
Time.setOffset(0) to the AbstractKeycloakRule.before/after to avoid 
similar issues in the future.

Marek

On 26.1.2015 15:48, Marek Posolda wrote:
> I will try to take a look at those.
>
> Marek
>
> On 26.1.2015 14:18, Stian Thorgersen wrote:
>> SyncProvidersTest.testLDAPSync and CookieTokenStoreAdapterTest.testTokenInCookieRefresh are failing for me once in a while. Also fails on Jenkins.
>>
>> Failed tests:
>>     SyncProvidersTest.testLDAPSync:142->assertUserImported:191 expected:<User5FN[Updated]> but was:<User5FN[]>
>>     CookieTokenStoreAdapterTest.testTokenInCookieRefresh:110 Values should be different. Actual: eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJzdWJqZWN0IjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiZ2l2ZW5fbmFtZSI6IkJpbGwiLCJmYW1pbHlfbmFtZSI6IkJ1cmtlIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsImp0aSI6IjBlMWI0Mzc4LWVjMGQtNDIzMS04NmU4LWI1YjNkYjA0NWNkNiIsImV4cCI6MTQyMjI2MzY0NCwibmJmIjowLCJpYXQiOjE0MjIyNjM2NDEsImlzcyI6ImRlbW8iLCJhdWQiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiYXpwIjoiY3VzdG9tZXItY29va2llLXBvcnRhbCIsInNlc3Npb25fc3RhdGUiOiIwNjBmM2FjYy1jZDkxLTQwZTUtOTEzOS1lODRlMTNiMmY3MDkiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cDovL2xvY2FsaG9zdDo4MDgxIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCJdfX19.Zzdkc!
>   x-L!
>>    bBPtX_xCGjxBT2d8VOzwSP8i8XdiSsfpOotPGN0D7aiehb3QrvXjYcFOMgkutWNMfZxeNcJ9iN3kxcV7IA6AYchVPLo-WX1fUmRiUbpghophQA5pjbxB3Riqn5W0G6A_zFvkPRPQohXeiO_Wq0Ao_mBQGvhZg1RN0u0 at eyJhbGciOiJSUzI1NiJ9.eyJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJnaXZlbl9uYW1lIjoiQmlsbCIsImZhbWlseV9uYW1lIjoiQnVya2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJiYnVya2VAcmVkaGF0LmNvbSIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwianRpIjoiNDk0OGYzNjktMGJmOS00MTA0LTg3ZjUtZGIzYWExZGE0Nzg0IiwiZXhwIjoxNDIyMjYzNjQ0LCJuYmYiOjAsImlhdCI6MTQyMjI2MzY0MSwiaXNzIjoiZGVtbyIsImF1ZCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJhenAiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIn0.m6n2f2uJUPapm3L73PgtB0Lqyqi7dZgzI0G_9-X7G9DUq0dB-h5GJVezfLmVlESjuw2K7Jn3urEwjD_gTShecEDGnJeSfi-EYRbBQvolcATapT8wN7-LabP95MdIH3ustnjQExhXNYxGG0QlA1c4oA9OebLzG-SX314U5Ha6-OQ@eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJlN2FkMzEyNC1lNzk0LTRiMDEtYTAxOS1mN2NjODQzNmZiYTIiLCJleHAiOjE0MjIyNjU0NDEsIm5iZiI6MCwiaWF0IjoxNDIyMjYzNjQxLCJpc3M!
>   iOi!
>>    JkZW1vIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcy!
>>    NTY1Iiwi
>> dHlwIjoiUkVGUkVTSCIsImF6cCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzZXNzaW9uX3N0YXRlIjoiMDYwZjNhY2MtY2Q5MS00MGU1LTkxMzktZTg0ZTEzYjJmNzA5IiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Il19fX0.prz4dbCq66DqnpAudzfcghuYje30D96MSuVWqk9pIVVmx5-4qMIDCfoS3hbeJpV98OYlRHSpKBQI-FTTWEm-mWKBY30SAzutbwbf7nXG3TuF5-lId3tNsc_tA72XW9HoEAW9_AVA8_w4L51D7D_x7RnFiRa7k2WDaRjlrF9nBQk
>>
>>
>> Anyone know why these are failing?
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




From gerbermichi at me.com  Mon Jan 26 12:12:40 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 26 Jan 2015 18:12:40 +0100
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <54C6633B.3080106@redhat.com>
References: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>
	<54C640C2.1080000@redhat.com>
	<1347626282.420665.1422279917422.JavaMail.zimbra@redhat.com>
	<54C6633B.3080106@redhat.com>
Message-ID: <8BDBE03A-D555-420F-B8EF-ED1337C17789@me.com>


> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com>:
> 
> 
> 
>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Monday, January 26, 2015 2:27:30 PM
>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>> 
>>> Wouldn't this work?
>>> 
>>> 1) store "state" of state cookie in user session.
>>> 2) embed user session and state of state cookie in URL
>>> 
>>> Of course this screws up your "shorter URL" crusade.
>> 
>> I'm not following - the problem isn't remembering the state variable in Keycloak, that's already sorted as we already store all the query params passed by the client in the client session (state, redirect_uri, etc). The problem is storing it on the adapter side.
> 
> I think I get it...
> 
> 
> 1. Send email
> 2. Close browser
> 3. Open browser
> 4. Click email link
> 5. Reset password
> 6. Redirect back to app
> 7. App barfs because of state cookie
> 
> 
> Persistent state cookie sounds like cleanest and simplest solution. I 
> just worry we'll introduce different bugs, or if we're opening up some 
> kind of security hole.  Maybe I'm just paranoid.
That doesn't work if the user uses two different browsers. This is the case in a lot of companies (at least in Switzerland :)) where the users are forced to use ie (default) but rather work with firefox. 
> 
> Another possibility:
> 
> * Maybe set a auth server session cookie.  If that cookie isn't set, 
> just redirect to a auth server page that says "Password was reset" and 
> don't redirect back to the application.
> 
> 
> 
> -- 
> 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 Jan 26 12:18:08 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jan 2015 12:18:08 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com> <54C2D0E5.3030702@redhat.com>
	<54C38976.2060807@redhat.com> <54C5A07C.1050102@redhat.com>
	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
	<54C63051.4070608@redhat.com>
	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
Message-ID: <54C676D0.6010306@redhat.com>

Can't find the magic...Keep getting this error:

12:15:21,803 INFO 
[org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service 
thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file 
in the classpath


persistence.xml is in this module:


<module xmlns="urn:jboss:module:1.1" 
name="org.keycloak.keycloak-connections-jpa">
     <resources>
         <resource-root 
path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
         <!-- Insert resources here -->
     </resources>
     <exports>
         <include path="META-INF/**" />
     </exports>
     <dependencies>
         <module name="org.keycloak.keycloak-core"/>
         <module name="org.keycloak.keycloak-model-api"/>
         <module name="javax.persistence.api"/>
         <module name="org.jboss.logging"/>
         <module name="javax.api"/>
         <module name="org.hibernate" services="import">
             <imports>
             <include path="META-INF/**" />
         </imports>
         </module>
     </dependencies>

</module>


On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, January 26, 2015 1:17:21 PM
>> Subject: Re: [keycloak-dev] aggregate modules
>>
>>
>>
>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>
>>>>
>>>>
>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>> Ran into a wall:
>>>>>>
>>>>>> I couldn't have an aggregate module.  service imports didn't seem to
>>>>>> work so I had to create a dependency for everything within
>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
>>>>>> errors in my module defintions.
>>>>> In Brno I can ask David about this.  Can you post your
>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>
>>>>>> I'm at a wall.  I can't get the JPA connections to find the Hibernate
>>>>>> provider.  I"m not sure if it can't find persistence.xml or hibernate or
>>>>>> what.  Tried importing hibernate in various places to no avail.  Error
>>>>>> Message isn't very helpful either:
>>>>>>
>>>>>> javax.persistence.PersistenceException: No Persistence provider for
>>>>>> EntityManager named keycloak-default
>>>>> Can you give me a scaled down reproducer for this one?  I can ask around
>>>>> and see if anyone knows a solution.
>>>>
>>>> I think this is another service import problem.
>>>
>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>> META-INF/persistence.xml isn't exported/imported by default, see
>>> https://developer.jboss.org/message/828881#828881
>>>
>>> If you're fed up and commit your stuff I can take a look. I've gone done
>>> this in the past so should be able to get it to work again.
>>>
>>
>> Zoinks...I'll try importing META-INF.
>>
>> Are we sure we want users dealing with JBoss Modules?
>
> Yes ;)
>
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

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

From bburke at redhat.com  Mon Jan 26 12:36:46 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jan 2015 12:36:46 -0500
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <8BDBE03A-D555-420F-B8EF-ED1337C17789@me.com>
References: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>
	<54C640C2.1080000@redhat.com>
	<1347626282.420665.1422279917422.JavaMail.zimbra@redhat.com>
	<54C6633B.3080106@redhat.com>
	<8BDBE03A-D555-420F-B8EF-ED1337C17789@me.com>
Message-ID: <54C67B2E.7010901@redhat.com>



On 1/26/2015 12:12 PM, Michael Gerber wrote:
>
>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com>:
>>
>>
>>
>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, January 26, 2015 2:27:30 PM
>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>>>
>>>> Wouldn't this work?
>>>>
>>>> 1) store "state" of state cookie in user session.
>>>> 2) embed user session and state of state cookie in URL
>>>>
>>>> Of course this screws up your "shorter URL" crusade.
>>>
>>> I'm not following - the problem isn't remembering the state variable in Keycloak, that's already sorted as we already store all the query params passed by the client in the client session (state, redirect_uri, etc). The problem is storing it on the adapter side.
>>
>> I think I get it...
>>
>>
>> 1. Send email
>> 2. Close browser
>> 3. Open browser
>> 4. Click email link
>> 5. Reset password
>> 6. Redirect back to app
>> 7. App barfs because of state cookie
>>
>>
>> Persistent state cookie sounds like cleanest and simplest solution. I
>> just worry we'll introduce different bugs, or if we're opening up some
>> kind of security hole.  Maybe I'm just paranoid.
> That doesn't work if the user uses two different browsers. This is the case in a lot of companies (at least in Switzerland :)) where the users are forced to use ie (default) but rather work with firefox.

Unless we extend the protocol, or don't redirect from the email, I don't 
see a fix.


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

From bburke at redhat.com  Mon Jan 26 12:41:51 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jan 2015 12:41:51 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C676D0.6010306@redhat.com>
References: <54C15A15.50108@redhat.com>
	<54C2D0E5.3030702@redhat.com>	<54C38976.2060807@redhat.com>
	<54C5A07C.1050102@redhat.com>	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>	<54C63051.4070608@redhat.com>	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
	<54C676D0.6010306@redhat.com>
Message-ID: <54C67C5F.7080708@redhat.com>

I also tried this in jboss-deployment-structure.xml

             <module name="org.keycloak.keycloak-connections-jpa" 
services="import">
                 <imports>
                     <include path="META-INF/**"/>
                 </imports>
             </module>



On 1/26/2015 12:18 PM, Bill Burke wrote:
> Can't find the magic...Keep getting this error:
>
> 12:15:21,803 INFO
> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file
> in the classpath
>
>
> persistence.xml is in this module:
>
>
> <module xmlns="urn:jboss:module:1.1"
> name="org.keycloak.keycloak-connections-jpa">
>       <resources>
>           <resource-root
> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
>           <!-- Insert resources here -->
>       </resources>
>       <exports>
>           <include path="META-INF/**" />
>       </exports>
>       <dependencies>
>           <module name="org.keycloak.keycloak-core"/>
>           <module name="org.keycloak.keycloak-model-api"/>
>           <module name="javax.persistence.api"/>
>           <module name="org.jboss.logging"/>
>           <module name="javax.api"/>
>           <module name="org.hibernate" services="import">
>               <imports>
>               <include path="META-INF/**" />
>           </imports>
>           </module>
>       </dependencies>
>
> </module>
>
>
> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Monday, January 26, 2015 1:17:21 PM
>>> Subject: Re: [keycloak-dev] aggregate modules
>>>
>>>
>>>
>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>
>>>>>
>>>>>
>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>>> Ran into a wall:
>>>>>>>
>>>>>>> I couldn't have an aggregate module.  service imports didn't seem to
>>>>>>> work so I had to create a dependency for everything within
>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
>>>>>>> errors in my module defintions.
>>>>>> In Brno I can ask David about this.  Can you post your
>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>>
>>>>>>> I'm at a wall.  I can't get the JPA connections to find the Hibernate
>>>>>>> provider.  I"m not sure if it can't find persistence.xml or hibernate or
>>>>>>> what.  Tried importing hibernate in various places to no avail.  Error
>>>>>>> Message isn't very helpful either:
>>>>>>>
>>>>>>> javax.persistence.PersistenceException: No Persistence provider for
>>>>>>> EntityManager named keycloak-default
>>>>>> Can you give me a scaled down reproducer for this one?  I can ask around
>>>>>> and see if anyone knows a solution.
>>>>>
>>>>> I think this is another service import problem.
>>>>
>>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>>> META-INF/persistence.xml isn't exported/imported by default, see
>>>> https://developer.jboss.org/message/828881#828881
>>>>
>>>> If you're fed up and commit your stuff I can take a look. I've gone done
>>>> this in the past so should be able to get it to work again.
>>>>
>>>
>>> Zoinks...I'll try importing META-INF.
>>>
>>> Are we sure we want users dealing with JBoss Modules?
>>
>> Yes ;)
>>
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>

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

From gerbermichi at me.com  Mon Jan 26 13:31:44 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 26 Jan 2015 19:31:44 +0100
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <54C67B2E.7010901@redhat.com>
References: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>
	<54C640C2.1080000@redhat.com>
	<1347626282.420665.1422279917422.JavaMail.zimbra@redhat.com>
	<54C6633B.3080106@redhat.com>
	<8BDBE03A-D555-420F-B8EF-ED1337C17789@me.com>
	<54C67B2E.7010901@redhat.com>
Message-ID: <2AD625D5-A33C-44BE-A310-192BA6F350E2@me.com>


> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke at redhat.com>:
> 
> 
> 
> On 1/26/2015 12:12 PM, Michael Gerber wrote:
>> 
>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com>:
>>> 
>>> 
>>> 
>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>>>> 
>>>>> Wouldn't this work?
>>>>> 
>>>>> 1) store "state" of state cookie in user session.
>>>>> 2) embed user session and state of state cookie in URL
>>>>> 
>>>>> Of course this screws up your "shorter URL" crusade.
>>>> 
>>>> I'm not following - the problem isn't remembering the state variable in Keycloak, that's already sorted as we already store all the query params passed by the client in the client session (state, redirect_uri, etc). The problem is storing it on the adapter side.
>>> 
>>> I think I get it...
>>> 
>>> 
>>> 1. Send email
>>> 2. Close browser
>>> 3. Open browser
>>> 4. Click email link
>>> 5. Reset password
>>> 6. Redirect back to app
>>> 7. App barfs because of state cookie
>>> 
>>> 
>>> Persistent state cookie sounds like cleanest and simplest solution. I
>>> just worry we'll introduce different bugs, or if we're opening up some
>>> kind of security hole.  Maybe I'm just paranoid.
>> That doesn't work if the user uses two different browsers. This is the case in a lot of companies (at least in Switzerland :)) where the users are forced to use ie (default) but rather work with firefox.
> 
> Unless we extend the protocol, or don?t redirect from the email, I don?t see a fix.

If the password reset process would redirect without the code and state param, than the adapter would redirect back to the keycloak, and keycloak can authenticate the user with its identity cookie?
But I don?t know if that is ok with the protocol.

> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com <http://bill.burkecentral.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150126/5fca7be5/attachment-0001.html 

From bburke at redhat.com  Mon Jan 26 14:49:14 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Jan 2015 14:49:14 -0500
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <2AD625D5-A33C-44BE-A310-192BA6F350E2@me.com>
References: <12522191.404453.1422277629612.JavaMail.zimbra@redhat.com>
	<54C640C2.1080000@redhat.com>
	<1347626282.420665.1422279917422.JavaMail.zimbra@redhat.com>
	<54C6633B.3080106@redhat.com>
	<8BDBE03A-D555-420F-B8EF-ED1337C17789@me.com>
	<54C67B2E.7010901@redhat.com>
	<2AD625D5-A33C-44BE-A310-192BA6F350E2@me.com>
Message-ID: <54C69A3A.3070003@redhat.com>



On 1/26/2015 1:31 PM, Michael Gerber wrote:
>
>> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>>:
>>
>>
>>
>> On 1/26/2015 12:12 PM, Michael Gerber wrote:
>>>
>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com
>>>> <mailto:bburke at redhat.com>>:
>>>>
>>>>
>>>>
>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>>>>> To: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>>>>>
>>>>>> Wouldn't this work?
>>>>>>
>>>>>> 1) store "state" of state cookie in user session.
>>>>>> 2) embed user session and state of state cookie in URL
>>>>>>
>>>>>> Of course this screws up your "shorter URL" crusade.
>>>>>
>>>>> I'm not following - the problem isn't remembering the state
>>>>> variable in Keycloak, that's already sorted as we already store all
>>>>> the query params passed by the client in the client session (state,
>>>>> redirect_uri, etc). The problem is storing it on the adapter side.
>>>>
>>>> I think I get it...
>>>>
>>>>
>>>> 1. Send email
>>>> 2. Close browser
>>>> 3. Open browser
>>>> 4. Click email link
>>>> 5. Reset password
>>>> 6. Redirect back to app
>>>> 7. App barfs because of state cookie
>>>>
>>>>
>>>> Persistent state cookie sounds like cleanest and simplest solution. I
>>>> just worry we'll introduce different bugs, or if we're opening up some
>>>> kind of security hole.  Maybe I'm just paranoid.
>>> That doesn't work if the user uses two different browsers. This is
>>> the case in a lot of companies (at least in Switzerland :)) where the
>>> users are forced to use ie (default) but rather work with firefox.
>>
>> Unless we extend the protocol, or don?t redirect from the email, I
>> don?t see a fix.
>
> If the password reset process would redirect without the code and state
> param, than the adapter would redirect back to the keycloak, and
> keycloak can authenticate the user with its identity cookie?
> But I don?t know if that is ok with the protocol.
>

So maybe have a session cookie that is set by the auth server.  If that 
cookie is set when clicking the email url, redirect with code, if not, 
redirect without it.



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

From stian at redhat.com  Tue Jan 27 02:37:09 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jan 2015 02:37:09 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C67C5F.7080708@redhat.com>
References: <54C15A15.50108@redhat.com> <54C38976.2060807@redhat.com>
	<54C5A07C.1050102@redhat.com>
	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
	<54C63051.4070608@redhat.com>
	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
	<54C676D0.6010306@redhat.com> <54C67C5F.7080708@redhat.com>
Message-ID: <774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>

If you commit what you have to a branch I can take a look

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, January 26, 2015 6:41:51 PM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> I also tried this in jboss-deployment-structure.xml
> 
>              <module name="org.keycloak.keycloak-connections-jpa"
> services="import">
>                  <imports>
>                      <include path="META-INF/**"/>
>                  </imports>
>              </module>
> 
> 
> 
> On 1/26/2015 12:18 PM, Bill Burke wrote:
> > Can't find the magic...Keep getting this error:
> >
> > 12:15:21,803 INFO
> > [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
> > thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file
> > in the classpath
> >
> >
> > persistence.xml is in this module:
> >
> >
> > <module xmlns="urn:jboss:module:1.1"
> > name="org.keycloak.keycloak-connections-jpa">
> >       <resources>
> >           <resource-root
> > path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
> >           <!-- Insert resources here -->
> >       </resources>
> >       <exports>
> >           <include path="META-INF/**" />
> >       </exports>
> >       <dependencies>
> >           <module name="org.keycloak.keycloak-core"/>
> >           <module name="org.keycloak.keycloak-model-api"/>
> >           <module name="javax.persistence.api"/>
> >           <module name="org.jboss.logging"/>
> >           <module name="javax.api"/>
> >           <module name="org.hibernate" services="import">
> >               <imports>
> >               <include path="META-INF/**" />
> >           </imports>
> >           </module>
> >       </dependencies>
> >
> > </module>
> >
> >
> > On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Stian Thorgersen" <stian at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Monday, January 26, 2015 1:17:21 PM
> >>> Subject: Re: [keycloak-dev] aggregate modules
> >>>
> >>>
> >>>
> >>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: keycloak-dev at lists.jboss.org
> >>>>> Sent: Monday, January 26, 2015 3:03:40 AM
> >>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
> >>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
> >>>>>>> Ran into a wall:
> >>>>>>>
> >>>>>>> I couldn't have an aggregate module.  service imports didn't seem to
> >>>>>>> work so I had to create a dependency for everything within
> >>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
> >>>>>>> errors in my module defintions.
> >>>>>> In Brno I can ask David about this.  Can you post your
> >>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
> >>>>>>>
> >>>>>>> I'm at a wall.  I can't get the JPA connections to find the Hibernate
> >>>>>>> provider.  I"m not sure if it can't find persistence.xml or hibernate
> >>>>>>> or
> >>>>>>> what.  Tried importing hibernate in various places to no avail.
> >>>>>>> Error
> >>>>>>> Message isn't very helpful either:
> >>>>>>>
> >>>>>>> javax.persistence.PersistenceException: No Persistence provider for
> >>>>>>> EntityManager named keycloak-default
> >>>>>> Can you give me a scaled down reproducer for this one?  I can ask
> >>>>>> around
> >>>>>> and see if anyone knows a solution.
> >>>>>
> >>>>> I think this is another service import problem.
> >>>>
> >>>> Loading JPA in this way will work, but it's a bit of a PITA.
> >>>> META-INF/persistence.xml isn't exported/imported by default, see
> >>>> https://developer.jboss.org/message/828881#828881
> >>>>
> >>>> If you're fed up and commit your stuff I can take a look. I've gone done
> >>>> this in the past so should be able to get it to work again.
> >>>>
> >>>
> >>> Zoinks...I'll try importing META-INF.
> >>>
> >>> Are we sure we want users dealing with JBoss Modules?
> >>
> >> Yes ;)
> >>
> >>>
> >>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>>
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jan 27 02:42:53 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jan 2015 02:42:53 -0500 (EST)
Subject: [keycloak-dev] Intermittent test failures in
 SyncProvidersTest.testLDAPSync and
 CookieTokenStoreAdapterTest.testTokenInCookieRefresh
In-Reply-To: <54C66B2D.1050008@redhat.com>
References: <1926416125.409746.1422278304485.JavaMail.zimbra@redhat.com>
	<54C653D9.3010909@redhat.com> <54C66B2D.1050008@redhat.com>
Message-ID: <1003294806.848492.1422344573043.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, January 26, 2015 5:28:29 PM
> Subject: Re: [keycloak-dev] Intermittent test failures in SyncProvidersTest.testLDAPSync and
> CookieTokenStoreAdapterTest.testTokenInCookieRefresh
> 
> I think I have a fix (despite the fact I did not simulate test failure
> on my laptop ;-)
> 
> Commited to master and 1.1.x branches.
> 
> It's caused by uncleared offset on org.keycloak.util.Time, which is
> static and shared per the JVM for all tests. I wonder if we should put
> Time.setOffset(0) to the AbstractKeycloakRule.before/after to avoid
> similar issues in the future.

So it was my fault after all, usually is when master breaks ;)

I'll add the Time.setOffset(0) to AbstractKeycloakRule.

> 
> Marek
> 
> On 26.1.2015 15:48, Marek Posolda wrote:
> > I will try to take a look at those.
> >
> > Marek
> >
> > On 26.1.2015 14:18, Stian Thorgersen wrote:
> >> SyncProvidersTest.testLDAPSync and
> >> CookieTokenStoreAdapterTest.testTokenInCookieRefresh are failing for me
> >> once in a while. Also fails on Jenkins.
> >>
> >> Failed tests:
> >>     SyncProvidersTest.testLDAPSync:142->assertUserImported:191
> >>     expected:<User5FN[Updated]> but was:<User5FN[]>
> >>     CookieTokenStoreAdapterTest.testTokenInCookieRefresh:110 Values should
> >>     be different. Actual:
> >>     eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJzdWJqZWN0IjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiZ2l2ZW5fbmFtZSI6IkJpbGwiLCJmYW1pbHlfbmFtZSI6IkJ1cmtlIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsImp0aSI6IjBlMWI0Mzc4LWVjMGQtNDIzMS04NmU4LWI1YjNkYjA0NWNkNiIsImV4cCI6MTQyMjI2MzY0NCwibmJmIjowLCJpYXQiOjE0MjIyNjM2NDEsImlzcyI6ImRlbW8iLCJhdWQiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcyNTY1IiwiYXpwIjoiY3VzdG9tZXItY29va2llLXBvcnRhbCIsInNlc3Npb25fc3RhdGUiOiIwNjBmM2FjYy1jZDkxLTQwZTUtOTEzOS1lODRlMTNiMmY3MDkiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cDovL2xvY2FsaG9zdDo4MDgxIl0sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1c2VyIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCJdfX19.Zzdkc!
> >   x-L!
> >>    bBPtX_xCGjxBT2d8VOzwSP8i8XdiSsfpOotPGN0D7aiehb3QrvXjYcFOMgkutWNMfZxeNcJ9iN3kxcV7IA6AYchVPLo-WX1fUmRiUbpghophQA5pjbxB3Riqn5W0G6A_zFvkPRPQohXeiO_Wq0Ao_mBQGvhZg1RN0u0 at eyJhbGciOiJSUzI1NiJ9.eyJuYW1lIjoiQmlsbCBCdXJrZSIsImVtYWlsIjoiYmJ1cmtlQHJlZGhhdC5jb20iLCJnaXZlbl9uYW1lIjoiQmlsbCIsImZhbWlseV9uYW1lIjoiQnVya2UiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJiYnVya2VAcmVkaGF0LmNvbSIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwianRpIjoiNDk0OGYzNjktMGJmOS00MTA0LTg3ZjUtZGIzYWExZGE0Nzg0IiwiZXhwIjoxNDIyMjYzNjQ0LCJuYmYiOjAsImlhdCI6MTQyMjI2MzY0MSwiaXNzIjoiZGVtbyIsImF1ZCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzdWIiOiJiMTBlMjVlNS1mYTIyLTQwMjgtODg0Ny1mYTU4OWMxNzI1NjUiLCJhenAiOiJjdXN0b21lci1jb29raWUtcG9ydGFsIn0.m6n2f2uJUPapm3L73PgtB0Lqyqi7dZgzI0G_9-X7G9DUq0dB-h5GJVezfLmVlESjuw2K7Jn3urEwjD_gTShecEDGnJeSfi-EYRbBQvolcATapT8wN7-LabP95MdIH3ustnjQExhXNYxGG0QlA1c4oA9OebLzG-SX314U5Ha6-OQ@eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJlN2FkMzEyNC1lNzk0LTRiMDEtYTAxOS1mN2NjODQzNmZiYTIiLCJleHAiOjE0MjIyNjU0NDEsIm5iZiI6MCwiaWF0IjoxNDIyMjYzNjQxLCJpc3M!
> >   iOi!
> >>    JkZW1vIiwic3ViIjoiYjEwZTI1ZTUtZmEyMi00MDI4LTg4NDctZmE1ODljMTcy!
> >>    NTY1Iiwi
> >> dHlwIjoiUkVGUkVTSCIsImF6cCI6ImN1c3RvbWVyLWNvb2tpZS1wb3J0YWwiLCJzZXNzaW9uX3N0YXRlIjoiMDYwZjNhY2MtY2Q5MS00MGU1LTkxMzktZTg0ZTEzYjJmNzA5IiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Il19fX0.prz4dbCq66DqnpAudzfcghuYje30D96MSuVWqk9pIVVmx5-4qMIDCfoS3hbeJpV98OYlRHSpKBQI-FTTWEm-mWKBY30SAzutbwbf7nXG3TuF5-lId3tNsc_tA72XW9HoEAW9_AVA8_w4L51D7D_x7RnFiRa7k2WDaRjlrF9nBQk
> >>
> >>
> >> Anyone know why these are failing?
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
>


From gerbermichi at me.com  Tue Jan 27 04:33:09 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 27 Jan 2015 09:33:09 +0000 (GMT)
Subject: [keycloak-dev] Rest password can cause cookie not found
Message-ID: <b6be3064-b6e4-4335-aba7-8191de7d9dbc@me.com>



Am 26. Januar 2015 um 20:49 schrieb Bill Burke <bburke at redhat.com>:

>
>
> On 1/26/2015 1:31 PM, Michael Gerber wrote:
>>> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke at redhat.com
>>>  
>>> <mailto:bburke at redhat.com>>:
>>> On 1/26/2015 12:12 PM, Michael Gerber wrote:
>>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com
>>>>>  
>>>>> <mailto:bburke at redhat.com>>:
>>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>>>>>> To: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
>>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>>>>>> Wouldn't this work?
>>>>>>> 1) store "state" of state cookie in user session.
>>>>>>> 2) embed user session and state of state cookie in URL
>>>>>>> Of course this screws up your "shorter URL" crusade.
>>>>>> I'm not following - the problem isn't remembering the state
>>>>>> variable in Keycloak, that's already sorted as we already store all
>>>>>> the query params passed by the client in the client session (state,
>>>>>> redirect_uri, etc). The problem is storing it on the adapter side.
>>>>> I think I get it...
>>>>> 1. Send email
>>>>> 2. Close browser
>>>>> 3. Open browser
>>>>> 4. Click email link
>>>>> 5. Reset password
>>>>> 6. Redirect back to app
>>>>> 7. App barfs because of state cookie
>>>>> Persistent state cookie sounds like cleanest and simplest solution. I
>>>>> just worry we'll introduce different bugs, or if we're opening up some
>>>>> kind of security hole. Maybe I'm just paranoid.
>>>> That doesn't work if the user uses two different browsers. This is
>>>> the case in a lot of companies (at least in Switzerland :)) where the
>>>> users are forced to use ie (default) but rather work with firefox.
>>> Unless we extend the protocol, or don?t redirect from the email, I
>>> don?t see a fix.
>> If the password reset process would redirect without the code and state
>> param, than the adapter would redirect back to the keycloak, and
>> keycloak can authenticate the user with its identity cookie?
>> But I don?t know if that is ok with the protocol.
>
> So maybe have a session cookie that is set by the auth server. If that
> cookie is set when clicking the email url, redirect with code, if not,
> redirect without it.
>
 
That sounds good, what do the other think about this fallback option?
I can update the JIRA issue if anybody is happy with th?at solution.
>
>
> -- 
> 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/20150127/af13bd67/attachment-0001.html 

From stian at redhat.com  Tue Jan 27 04:49:11 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jan 2015 04:49:11 -0500 (EST)
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <b6be3064-b6e4-4335-aba7-8191de7d9dbc@me.com>
References: <b6be3064-b6e4-4335-aba7-8191de7d9dbc@me.com>
Message-ID: <68899949.988176.1422352151170.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 27, 2015 10:33:09 AM
> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> 
> 
> 
> Am 26. Januar 2015 um 20:49 schrieb Bill Burke <bburke at redhat.com>:
> 
> >
> >
> > On 1/26/2015 1:31 PM, Michael Gerber wrote:
> >>> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke at redhat.com
> >>>  
> >>> <mailto:bburke at redhat.com>>:
> >>> On 1/26/2015 12:12 PM, Michael Gerber wrote:
> >>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com
> >>>>>  
> >>>>> <mailto:bburke at redhat.com>>:
> >>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> <mailto:keycloak-dev at lists.jboss.org>
> >>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
> >>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> >>>>>>> Wouldn't this work?
> >>>>>>> 1) store "state" of state cookie in user session.
> >>>>>>> 2) embed user session and state of state cookie in URL
> >>>>>>> Of course this screws up your "shorter URL" crusade.
> >>>>>> I'm not following - the problem isn't remembering the state
> >>>>>> variable in Keycloak, that's already sorted as we already store all
> >>>>>> the query params passed by the client in the client session (state,
> >>>>>> redirect_uri, etc). The problem is storing it on the adapter side.
> >>>>> I think I get it...
> >>>>> 1. Send email
> >>>>> 2. Close browser
> >>>>> 3. Open browser
> >>>>> 4. Click email link
> >>>>> 5. Reset password
> >>>>> 6. Redirect back to app
> >>>>> 7. App barfs because of state cookie
> >>>>> Persistent state cookie sounds like cleanest and simplest solution. I
> >>>>> just worry we'll introduce different bugs, or if we're opening up some
> >>>>> kind of security hole. Maybe I'm just paranoid.
> >>>> That doesn't work if the user uses two different browsers. This is
> >>>> the case in a lot of companies (at least in Switzerland :)) where the
> >>>> users are forced to use ie (default) but rather work with firefox.
> >>> Unless we extend the protocol, or don?t redirect from the email, I
> >>> don?t see a fix.
> >> If the password reset process would redirect without the code and state
> >> param, than the adapter would redirect back to the keycloak, and
> >> keycloak can authenticate the user with its identity cookie?
> >> But I don?t know if that is ok with the protocol.
> >
> > So maybe have a session cookie that is set by the auth server. If that
> > cookie is set when clicking the email url, redirect with code, if not,
> > redirect without it.
> >
>  
> That sounds good, what do the other think about this fallback option?
> I can update the JIRA issue if anybody is happy with th?at solution.

I'm happy with the idea of setting a session cookie so we can detect if a user is using the same browser to complete the flow. However, I don't think we should redirect back to the application.

In this case the user most likely wants to use a different browser for the application. For example a user uses Firefox to open the application, click on recover password, but then due to company policies IE is registered as the default OS browser so links in emails are opened in IE instead. In this case the user wants to close IE after resetting the password and go back to Firefox to use the application.

In the case the user is completing the password reset flow in a different browser it would be better to update the password, make sure no identity cookie or user session is created in the new browser, then just display a message "Your password has been updated".

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


From stian at redhat.com  Tue Jan 27 06:03:28 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jan 2015 06:03:28 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com> <54C5A07C.1050102@redhat.com>
	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
	<54C63051.4070608@redhat.com>
	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
	<54C676D0.6010306@redhat.com> <54C67C5F.7080708@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
Message-ID: <1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>

Had a play with this and I've got an example WAR loading persistence.xml from a module working.

To try it on WildFly 8.2.0.Final:

1. Build and deploy module + war to WildFly

# git clone https://github.com/stianst/playtime.git
# cd playtime
# mvn install
# unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d $JBOSS_HOME
# cp jpa/target/playtime-jpa-1-SNAPSHOT.war $JBOSS_HOME/standalone/deployments/

2. Start WildFly

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 27, 2015 8:37:09 AM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> If you commit what you have to a branch I can take a look
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Monday, January 26, 2015 6:41:51 PM
> > Subject: Re: [keycloak-dev] aggregate modules
> > 
> > I also tried this in jboss-deployment-structure.xml
> > 
> >              <module name="org.keycloak.keycloak-connections-jpa"
> > services="import">
> >                  <imports>
> >                      <include path="META-INF/**"/>
> >                  </imports>
> >              </module>
> > 
> > 
> > 
> > On 1/26/2015 12:18 PM, Bill Burke wrote:
> > > Can't find the magic...Keep getting this error:
> > >
> > > 12:15:21,803 INFO
> > > [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
> > > thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file
> > > in the classpath
> > >
> > >
> > > persistence.xml is in this module:
> > >
> > >
> > > <module xmlns="urn:jboss:module:1.1"
> > > name="org.keycloak.keycloak-connections-jpa">
> > >       <resources>
> > >           <resource-root
> > > path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
> > >           <!-- Insert resources here -->
> > >       </resources>
> > >       <exports>
> > >           <include path="META-INF/**" />
> > >       </exports>
> > >       <dependencies>
> > >           <module name="org.keycloak.keycloak-core"/>
> > >           <module name="org.keycloak.keycloak-model-api"/>
> > >           <module name="javax.persistence.api"/>
> > >           <module name="org.jboss.logging"/>
> > >           <module name="javax.api"/>
> > >           <module name="org.hibernate" services="import">
> > >               <imports>
> > >               <include path="META-INF/**" />
> > >           </imports>
> > >           </module>
> > >       </dependencies>
> > >
> > > </module>
> > >
> > >
> > > On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Bill Burke" <bburke at redhat.com>
> > >>> To: "Stian Thorgersen" <stian at redhat.com>
> > >>> Cc: keycloak-dev at lists.jboss.org
> > >>> Sent: Monday, January 26, 2015 1:17:21 PM
> > >>> Subject: Re: [keycloak-dev] aggregate modules
> > >>>
> > >>>
> > >>>
> > >>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>> To: keycloak-dev at lists.jboss.org
> > >>>>> Sent: Monday, January 26, 2015 3:03:40 AM
> > >>>>> Subject: Re: [keycloak-dev] aggregate modules
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
> > >>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
> > >>>>>>> Ran into a wall:
> > >>>>>>>
> > >>>>>>> I couldn't have an aggregate module.  service imports didn't seem
> > >>>>>>> to
> > >>>>>>> work so I had to create a dependency for everything within
> > >>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot
> > >>>>>>> of
> > >>>>>>> errors in my module defintions.
> > >>>>>> In Brno I can ask David about this.  Can you post your
> > >>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
> > >>>>>>>
> > >>>>>>> I'm at a wall.  I can't get the JPA connections to find the
> > >>>>>>> Hibernate
> > >>>>>>> provider.  I"m not sure if it can't find persistence.xml or
> > >>>>>>> hibernate
> > >>>>>>> or
> > >>>>>>> what.  Tried importing hibernate in various places to no avail.
> > >>>>>>> Error
> > >>>>>>> Message isn't very helpful either:
> > >>>>>>>
> > >>>>>>> javax.persistence.PersistenceException: No Persistence provider for
> > >>>>>>> EntityManager named keycloak-default
> > >>>>>> Can you give me a scaled down reproducer for this one?  I can ask
> > >>>>>> around
> > >>>>>> and see if anyone knows a solution.
> > >>>>>
> > >>>>> I think this is another service import problem.
> > >>>>
> > >>>> Loading JPA in this way will work, but it's a bit of a PITA.
> > >>>> META-INF/persistence.xml isn't exported/imported by default, see
> > >>>> https://developer.jboss.org/message/828881#828881
> > >>>>
> > >>>> If you're fed up and commit your stuff I can take a look. I've gone
> > >>>> done
> > >>>> this in the past so should be able to get it to work again.
> > >>>>
> > >>>
> > >>> Zoinks...I'll try importing META-INF.
> > >>>
> > >>> Are we sure we want users dealing with JBoss Modules?
> > >>
> > >> Yes ;)
> > >>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Bill Burke
> > >>> JBoss, a division of Red Hat
> > >>> http://bill.burkecentral.com
> > >>>
> > >
> > 
> > --
> > 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 ssilvert at redhat.com  Tue Jan 27 06:50:44 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 27 Jan 2015 06:50:44 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com> <54C5A07C.1050102@redhat.com>
	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
	<54C63051.4070608@redhat.com>
	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
	<54C676D0.6010306@redhat.com> <54C67C5F.7080708@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
Message-ID: <54C77B94.80507@redhat.com>

I have some news on this. Adding/updating modules in a domain is not 
available yet.  Flavia is supposed to work on it when she is back.  I 
don't know the details of how it will work or what WildFly version it 
will work on.


On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
> Had a play with this and I've got an example WAR loading persistence.xml from a module working.
>
> To try it on WildFly 8.2.0.Final:
>
> 1. Build and deploy module + war to WildFly
>
> # git clone https://github.com/stianst/playtime.git
> # cd playtime
> # mvn install
> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d $JBOSS_HOME
> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war $JBOSS_HOME/standalone/deployments/
>
> 2. Start WildFly
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, January 27, 2015 8:37:09 AM
>> Subject: Re: [keycloak-dev] aggregate modules
>>
>> If you commit what you have to a branch I can take a look
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Monday, January 26, 2015 6:41:51 PM
>>> Subject: Re: [keycloak-dev] aggregate modules
>>>
>>> I also tried this in jboss-deployment-structure.xml
>>>
>>>               <module name="org.keycloak.keycloak-connections-jpa"
>>> services="import">
>>>                   <imports>
>>>                       <include path="META-INF/**"/>
>>>                   </imports>
>>>               </module>
>>>
>>>
>>>
>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
>>>> Can't find the magic...Keep getting this error:
>>>>
>>>> 12:15:21,803 INFO
>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
>>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file
>>>> in the classpath
>>>>
>>>>
>>>> persistence.xml is in this module:
>>>>
>>>>
>>>> <module xmlns="urn:jboss:module:1.1"
>>>> name="org.keycloak.keycloak-connections-jpa">
>>>>        <resources>
>>>>            <resource-root
>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
>>>>            <!-- Insert resources here -->
>>>>        </resources>
>>>>        <exports>
>>>>            <include path="META-INF/**" />
>>>>        </exports>
>>>>        <dependencies>
>>>>            <module name="org.keycloak.keycloak-core"/>
>>>>            <module name="org.keycloak.keycloak-model-api"/>
>>>>            <module name="javax.persistence.api"/>
>>>>            <module name="org.jboss.logging"/>
>>>>            <module name="javax.api"/>
>>>>            <module name="org.hibernate" services="import">
>>>>                <imports>
>>>>                <include path="META-INF/**" />
>>>>            </imports>
>>>>            </module>
>>>>        </dependencies>
>>>>
>>>> </module>
>>>>
>>>>
>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>>>>>> Ran into a wall:
>>>>>>>>>>
>>>>>>>>>> I couldn't have an aggregate module.  service imports didn't seem
>>>>>>>>>> to
>>>>>>>>>> work so I had to create a dependency for everything within
>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot
>>>>>>>>>> of
>>>>>>>>>> errors in my module defintions.
>>>>>>>>> In Brno I can ask David about this.  Can you post your
>>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
>>>>>>>>>> Hibernate
>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
>>>>>>>>>> hibernate
>>>>>>>>>> or
>>>>>>>>>> what.  Tried importing hibernate in various places to no avail.
>>>>>>>>>> Error
>>>>>>>>>> Message isn't very helpful either:
>>>>>>>>>>
>>>>>>>>>> javax.persistence.PersistenceException: No Persistence provider for
>>>>>>>>>> EntityManager named keycloak-default
>>>>>>>>> Can you give me a scaled down reproducer for this one?  I can ask
>>>>>>>>> around
>>>>>>>>> and see if anyone knows a solution.
>>>>>>>> I think this is another service import problem.
>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
>>>>>>> https://developer.jboss.org/message/828881#828881
>>>>>>>
>>>>>>> If you're fed up and commit your stuff I can take a look. I've gone
>>>>>>> done
>>>>>>> this in the past so should be able to get it to work again.
>>>>>>>
>>>>>> Zoinks...I'll try importing META-INF.
>>>>>>
>>>>>> Are we sure we want users dealing with JBoss Modules?
>>>>> Yes ;)
>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hat
>>>>>> http://bill.burkecentral.com
>>>>>>
>>> --
>>> 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  Tue Jan 27 08:00:29 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 27 Jan 2015 08:00:29 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com> <54C38976.2060807@redhat.com>
	<54C5A07C.1050102@redhat.com>
	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
	<54C63051.4070608@redhat.com>
	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
	<54C676D0.6010306@redhat.com> <54C67C5F.7080708@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
Message-ID: <54C78BED.9000207@redhat.com>

git at github.com:patriot1burke/keycloak.git

b_1_1

All your bro...

On 1/27/2015 2:37 AM, Stian Thorgersen wrote:
> If you commit what you have to a branch I can take a look
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, January 26, 2015 6:41:51 PM
>> Subject: Re: [keycloak-dev] aggregate modules
>>
>> I also tried this in jboss-deployment-structure.xml
>>
>>               <module name="org.keycloak.keycloak-connections-jpa"
>> services="import">
>>                   <imports>
>>                       <include path="META-INF/**"/>
>>                   </imports>
>>               </module>
>>
>>
>>
>> On 1/26/2015 12:18 PM, Bill Burke wrote:
>>> Can't find the magic...Keep getting this error:
>>>
>>> 12:15:21,803 INFO
>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file
>>> in the classpath
>>>
>>>
>>> persistence.xml is in this module:
>>>
>>>
>>> <module xmlns="urn:jboss:module:1.1"
>>> name="org.keycloak.keycloak-connections-jpa">
>>>        <resources>
>>>            <resource-root
>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
>>>            <!-- Insert resources here -->
>>>        </resources>
>>>        <exports>
>>>            <include path="META-INF/**" />
>>>        </exports>
>>>        <dependencies>
>>>            <module name="org.keycloak.keycloak-core"/>
>>>            <module name="org.keycloak.keycloak-model-api"/>
>>>            <module name="javax.persistence.api"/>
>>>            <module name="org.jboss.logging"/>
>>>            <module name="javax.api"/>
>>>            <module name="org.hibernate" services="import">
>>>                <imports>
>>>                <include path="META-INF/**" />
>>>            </imports>
>>>            </module>
>>>        </dependencies>
>>>
>>> </module>
>>>
>>>
>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>
>>>>>
>>>>>
>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>>>>> Ran into a wall:
>>>>>>>>>
>>>>>>>>> I couldn't have an aggregate module.  service imports didn't seem to
>>>>>>>>> work so I had to create a dependency for everything within
>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot of
>>>>>>>>> errors in my module defintions.
>>>>>>>> In Brno I can ask David about this.  Can you post your
>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>>>>
>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the Hibernate
>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or hibernate
>>>>>>>>> or
>>>>>>>>> what.  Tried importing hibernate in various places to no avail.
>>>>>>>>> Error
>>>>>>>>> Message isn't very helpful either:
>>>>>>>>>
>>>>>>>>> javax.persistence.PersistenceException: No Persistence provider for
>>>>>>>>> EntityManager named keycloak-default
>>>>>>>> Can you give me a scaled down reproducer for this one?  I can ask
>>>>>>>> around
>>>>>>>> and see if anyone knows a solution.
>>>>>>>
>>>>>>> I think this is another service import problem.
>>>>>>
>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
>>>>>> https://developer.jboss.org/message/828881#828881
>>>>>>
>>>>>> If you're fed up and commit your stuff I can take a look. I've gone done
>>>>>> this in the past so should be able to get it to work again.
>>>>>>
>>>>>
>>>>> Zoinks...I'll try importing META-INF.
>>>>>
>>>>> Are we sure we want users dealing with JBoss Modules?
>>>>
>>>> Yes ;)
>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Tue Jan 27 08:08:25 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 27 Jan 2015 08:08:25 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com> <54C5A07C.1050102@redhat.com>
	<1121980817.243349.1422258229107.JavaMail.zimbra@redhat.com>
	<54C63051.4070608@redhat.com>
	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
	<54C676D0.6010306@redhat.com> <54C67C5F.7080708@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
Message-ID: <54C78DC9.8070304@redhat.com>

Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo in 
my persistence.xml file...I'm checking now to see if things work.  I'll 
try and implement some aggregate modules after make sure everything works.

FYI meta-inf="import" doesn't work within a module.xml file, so I 
assumed it wouldn't work inside jboss-structure.xml...

If you don't hear from me, my internet is either down or power is out, 
blizzard is here.

On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
> Had a play with this and I've got an example WAR loading persistence.xml from a module working.
>
> To try it on WildFly 8.2.0.Final:
>
> 1. Build and deploy module + war to WildFly
>
> # git clone https://github.com/stianst/playtime.git
> # cd playtime
> # mvn install
> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d $JBOSS_HOME
> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war $JBOSS_HOME/standalone/deployments/
>
> 2. Start WildFly
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, January 27, 2015 8:37:09 AM
>> Subject: Re: [keycloak-dev] aggregate modules
>>
>> If you commit what you have to a branch I can take a look
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Monday, January 26, 2015 6:41:51 PM
>>> Subject: Re: [keycloak-dev] aggregate modules
>>>
>>> I also tried this in jboss-deployment-structure.xml
>>>
>>>               <module name="org.keycloak.keycloak-connections-jpa"
>>> services="import">
>>>                   <imports>
>>>                       <include path="META-INF/**"/>
>>>                   </imports>
>>>               </module>
>>>
>>>
>>>
>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
>>>> Can't find the magic...Keep getting this error:
>>>>
>>>> 12:15:21,803 INFO
>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
>>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file
>>>> in the classpath
>>>>
>>>>
>>>> persistence.xml is in this module:
>>>>
>>>>
>>>> <module xmlns="urn:jboss:module:1.1"
>>>> name="org.keycloak.keycloak-connections-jpa">
>>>>        <resources>
>>>>            <resource-root
>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
>>>>            <!-- Insert resources here -->
>>>>        </resources>
>>>>        <exports>
>>>>            <include path="META-INF/**" />
>>>>        </exports>
>>>>        <dependencies>
>>>>            <module name="org.keycloak.keycloak-core"/>
>>>>            <module name="org.keycloak.keycloak-model-api"/>
>>>>            <module name="javax.persistence.api"/>
>>>>            <module name="org.jboss.logging"/>
>>>>            <module name="javax.api"/>
>>>>            <module name="org.hibernate" services="import">
>>>>                <imports>
>>>>                <include path="META-INF/**" />
>>>>            </imports>
>>>>            </module>
>>>>        </dependencies>
>>>>
>>>> </module>
>>>>
>>>>
>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>>>>>> Ran into a wall:
>>>>>>>>>>
>>>>>>>>>> I couldn't have an aggregate module.  service imports didn't seem
>>>>>>>>>> to
>>>>>>>>>> work so I had to create a dependency for everything within
>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot
>>>>>>>>>> of
>>>>>>>>>> errors in my module defintions.
>>>>>>>>> In Brno I can ask David about this.  Can you post your
>>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>>>>>
>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
>>>>>>>>>> Hibernate
>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
>>>>>>>>>> hibernate
>>>>>>>>>> or
>>>>>>>>>> what.  Tried importing hibernate in various places to no avail.
>>>>>>>>>> Error
>>>>>>>>>> Message isn't very helpful either:
>>>>>>>>>>
>>>>>>>>>> javax.persistence.PersistenceException: No Persistence provider for
>>>>>>>>>> EntityManager named keycloak-default
>>>>>>>>> Can you give me a scaled down reproducer for this one?  I can ask
>>>>>>>>> around
>>>>>>>>> and see if anyone knows a solution.
>>>>>>>>
>>>>>>>> I think this is another service import problem.
>>>>>>>
>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
>>>>>>> https://developer.jboss.org/message/828881#828881
>>>>>>>
>>>>>>> If you're fed up and commit your stuff I can take a look. I've gone
>>>>>>> done
>>>>>>> this in the past so should be able to get it to work again.
>>>>>>>
>>>>>>
>>>>>> Zoinks...I'll try importing META-INF.
>>>>>>
>>>>>> Are we sure we want users dealing with JBoss Modules?
>>>>>
>>>>> Yes ;)
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hat
>>>>>> http://bill.burkecentral.com
>>>>>>
>>>>
>>>
>>> --
>>> 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 stian at redhat.com  Tue Jan 27 08:46:56 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jan 2015 08:46:56 -0500 (EST)
Subject: [keycloak-dev] Automatic tests on push and PRs to Keycloak
In-Reply-To: <295719850.1285332.1422365915264.JavaMail.zimbra@redhat.com>
Message-ID: <341395634.1309416.1422366416700.JavaMail.zimbra@redhat.com>

All,

Travis CI is now running tests automatically when there's a new push or PR to Keycloak. The results can be seen here https://travis-ci.org/keycloak/keycloak, but Travis also adds the status of the tests to each PRs comment section.

This only tests JDK7 and H2 in-mem, so we still need Jenkins for that. I've changed Jenkins to not run any tests on pushes, but instead it runs all tests every 24h.

From stian at redhat.com  Tue Jan 27 09:17:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jan 2015 09:17:07 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C78DC9.8070304@redhat.com>
References: <54C15A15.50108@redhat.com> <54C63051.4070608@redhat.com>
	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
	<54C676D0.6010306@redhat.com> <54C67C5F.7080708@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
	<54C78DC9.8070304@redhat.com>
Message-ID: <1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>

Does it make sense to hold off on extracting libs into modules and supporting loading providers from modules until after 1.1.0.Final?

It may be risky to introduce such a big change just before releasing a final? We can still add support for loading providers from the file-system as that's a much smaller change and only affects custom providers.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 27, 2015 2:08:25 PM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo in
> my persistence.xml file...I'm checking now to see if things work.  I'll
> try and implement some aggregate modules after make sure everything works.
> 
> FYI meta-inf="import" doesn't work within a module.xml file, so I
> assumed it wouldn't work inside jboss-structure.xml...
> 
> If you don't hear from me, my internet is either down or power is out,
> blizzard is here.
> 
> On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
> > Had a play with this and I've got an example WAR loading persistence.xml
> > from a module working.
> >
> > To try it on WildFly 8.2.0.Final:
> >
> > 1. Build and deploy module + war to WildFly
> >
> > # git clone https://github.com/stianst/playtime.git
> > # cd playtime
> > # mvn install
> > # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d
> > $JBOSS_HOME
> > # cp jpa/target/playtime-jpa-1-SNAPSHOT.war
> > $JBOSS_HOME/standalone/deployments/
> >
> > 2. Start WildFly
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, January 27, 2015 8:37:09 AM
> >> Subject: Re: [keycloak-dev] aggregate modules
> >>
> >> If you commit what you have to a branch I can take a look
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Monday, January 26, 2015 6:41:51 PM
> >>> Subject: Re: [keycloak-dev] aggregate modules
> >>>
> >>> I also tried this in jboss-deployment-structure.xml
> >>>
> >>>               <module name="org.keycloak.keycloak-connections-jpa"
> >>> services="import">
> >>>                   <imports>
> >>>                       <include path="META-INF/**"/>
> >>>                   </imports>
> >>>               </module>
> >>>
> >>>
> >>>
> >>> On 1/26/2015 12:18 PM, Bill Burke wrote:
> >>>> Can't find the magic...Keep getting this error:
> >>>>
> >>>> 12:15:21,803 INFO
> >>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
> >>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file
> >>>> in the classpath
> >>>>
> >>>>
> >>>> persistence.xml is in this module:
> >>>>
> >>>>
> >>>> <module xmlns="urn:jboss:module:1.1"
> >>>> name="org.keycloak.keycloak-connections-jpa">
> >>>>        <resources>
> >>>>            <resource-root
> >>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
> >>>>            <!-- Insert resources here -->
> >>>>        </resources>
> >>>>        <exports>
> >>>>            <include path="META-INF/**" />
> >>>>        </exports>
> >>>>        <dependencies>
> >>>>            <module name="org.keycloak.keycloak-core"/>
> >>>>            <module name="org.keycloak.keycloak-model-api"/>
> >>>>            <module name="javax.persistence.api"/>
> >>>>            <module name="org.jboss.logging"/>
> >>>>            <module name="javax.api"/>
> >>>>            <module name="org.hibernate" services="import">
> >>>>                <imports>
> >>>>                <include path="META-INF/**" />
> >>>>            </imports>
> >>>>            </module>
> >>>>        </dependencies>
> >>>>
> >>>> </module>
> >>>>
> >>>>
> >>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
> >>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
> >>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
> >>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
> >>>>>>>>>> Ran into a wall:
> >>>>>>>>>>
> >>>>>>>>>> I couldn't have an aggregate module.  service imports didn't seem
> >>>>>>>>>> to
> >>>>>>>>>> work so I had to create a dependency for everything within
> >>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot
> >>>>>>>>>> of
> >>>>>>>>>> errors in my module defintions.
> >>>>>>>>> In Brno I can ask David about this.  Can you post your
> >>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
> >>>>>>>>>>
> >>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
> >>>>>>>>>> Hibernate
> >>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
> >>>>>>>>>> hibernate
> >>>>>>>>>> or
> >>>>>>>>>> what.  Tried importing hibernate in various places to no avail.
> >>>>>>>>>> Error
> >>>>>>>>>> Message isn't very helpful either:
> >>>>>>>>>>
> >>>>>>>>>> javax.persistence.PersistenceException: No Persistence provider
> >>>>>>>>>> for
> >>>>>>>>>> EntityManager named keycloak-default
> >>>>>>>>> Can you give me a scaled down reproducer for this one?  I can ask
> >>>>>>>>> around
> >>>>>>>>> and see if anyone knows a solution.
> >>>>>>>>
> >>>>>>>> I think this is another service import problem.
> >>>>>>>
> >>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
> >>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
> >>>>>>> https://developer.jboss.org/message/828881#828881
> >>>>>>>
> >>>>>>> If you're fed up and commit your stuff I can take a look. I've gone
> >>>>>>> done
> >>>>>>> this in the past so should be able to get it to work again.
> >>>>>>>
> >>>>>>
> >>>>>> Zoinks...I'll try importing META-INF.
> >>>>>>
> >>>>>> Are we sure we want users dealing with JBoss Modules?
> >>>>>
> >>>>> Yes ;)
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Bill Burke
> >>>>>> JBoss, a division of Red Hat
> >>>>>> http://bill.burkecentral.com
> >>>>>>
> >>>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Tue Jan 27 09:40:47 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 27 Jan 2015 09:40:47 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com> <54C63051.4070608@redhat.com>
	<1540614330.379238.1422275170018.JavaMail.zimbra@redhat.com>
	<54C676D0.6010306@redhat.com> <54C67C5F.7080708@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
	<54C78DC9.8070304@redhat.com>
	<1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>
Message-ID: <54C7A36F.5070308@redhat.com>

Got a little further...Now can't find a Bouncycastle class even though I 
import it everywhere...

+1000 for putting this off.  This is what I was trying to suggest from 
the beginning.

On 1/27/2015 9:17 AM, Stian Thorgersen wrote:
> Does it make sense to hold off on extracting libs into modules and supporting loading providers from modules until after 1.1.0.Final?
>
> It may be risky to introduce such a big change just before releasing a final? We can still add support for loading providers from the file-system as that's a much smaller change and only affects custom providers.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, January 27, 2015 2:08:25 PM
>> Subject: Re: [keycloak-dev] aggregate modules
>>
>> Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo in
>> my persistence.xml file...I'm checking now to see if things work.  I'll
>> try and implement some aggregate modules after make sure everything works.
>>
>> FYI meta-inf="import" doesn't work within a module.xml file, so I
>> assumed it wouldn't work inside jboss-structure.xml...
>>
>> If you don't hear from me, my internet is either down or power is out,
>> blizzard is here.
>>
>> On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
>>> Had a play with this and I've got an example WAR loading persistence.xml
>>> from a module working.
>>>
>>> To try it on WildFly 8.2.0.Final:
>>>
>>> 1. Build and deploy module + war to WildFly
>>>
>>> # git clone https://github.com/stianst/playtime.git
>>> # cd playtime
>>> # mvn install
>>> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d
>>> $JBOSS_HOME
>>> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war
>>> $JBOSS_HOME/standalone/deployments/
>>>
>>> 2. Start WildFly
>>>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Bill Burke" <bburke at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, January 27, 2015 8:37:09 AM
>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>
>>>> If you commit what you have to a branch I can take a look
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Monday, January 26, 2015 6:41:51 PM
>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>
>>>>> I also tried this in jboss-deployment-structure.xml
>>>>>
>>>>>                <module name="org.keycloak.keycloak-connections-jpa"
>>>>> services="import">
>>>>>                    <imports>
>>>>>                        <include path="META-INF/**"/>
>>>>>                    </imports>
>>>>>                </module>
>>>>>
>>>>>
>>>>>
>>>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
>>>>>> Can't find the magic...Keep getting this error:
>>>>>>
>>>>>> 12:15:21,803 INFO
>>>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
>>>>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml file
>>>>>> in the classpath
>>>>>>
>>>>>>
>>>>>> persistence.xml is in this module:
>>>>>>
>>>>>>
>>>>>> <module xmlns="urn:jboss:module:1.1"
>>>>>> name="org.keycloak.keycloak-connections-jpa">
>>>>>>         <resources>
>>>>>>             <resource-root
>>>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
>>>>>>             <!-- Insert resources here -->
>>>>>>         </resources>
>>>>>>         <exports>
>>>>>>             <include path="META-INF/**" />
>>>>>>         </exports>
>>>>>>         <dependencies>
>>>>>>             <module name="org.keycloak.keycloak-core"/>
>>>>>>             <module name="org.keycloak.keycloak-model-api"/>
>>>>>>             <module name="javax.persistence.api"/>
>>>>>>             <module name="org.jboss.logging"/>
>>>>>>             <module name="javax.api"/>
>>>>>>             <module name="org.hibernate" services="import">
>>>>>>                 <imports>
>>>>>>                 <include path="META-INF/**" />
>>>>>>             </imports>
>>>>>>             </module>
>>>>>>         </dependencies>
>>>>>>
>>>>>> </module>
>>>>>>
>>>>>>
>>>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>>>>>>>> Ran into a wall:
>>>>>>>>>>>>
>>>>>>>>>>>> I couldn't have an aggregate module.  service imports didn't seem
>>>>>>>>>>>> to
>>>>>>>>>>>> work so I had to create a dependency for everything within
>>>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a lot
>>>>>>>>>>>> of
>>>>>>>>>>>> errors in my module defintions.
>>>>>>>>>>> In Brno I can ask David about this.  Can you post your
>>>>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
>>>>>>>>>>>> Hibernate
>>>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
>>>>>>>>>>>> hibernate
>>>>>>>>>>>> or
>>>>>>>>>>>> what.  Tried importing hibernate in various places to no avail.
>>>>>>>>>>>> Error
>>>>>>>>>>>> Message isn't very helpful either:
>>>>>>>>>>>>
>>>>>>>>>>>> javax.persistence.PersistenceException: No Persistence provider
>>>>>>>>>>>> for
>>>>>>>>>>>> EntityManager named keycloak-default
>>>>>>>>>>> Can you give me a scaled down reproducer for this one?  I can ask
>>>>>>>>>>> around
>>>>>>>>>>> and see if anyone knows a solution.
>>>>>>>>>>
>>>>>>>>>> I think this is another service import problem.
>>>>>>>>>
>>>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>>>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
>>>>>>>>> https://developer.jboss.org/message/828881#828881
>>>>>>>>>
>>>>>>>>> If you're fed up and commit your stuff I can take a look. I've gone
>>>>>>>>> done
>>>>>>>>> this in the past so should be able to get it to work again.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Zoinks...I'll try importing META-INF.
>>>>>>>>
>>>>>>>> Are we sure we want users dealing with JBoss Modules?
>>>>>>>
>>>>>>> Yes ;)
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> JBoss, a division of Red Hat
>>>>>>>> http://bill.burkecentral.com
>>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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
>>

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

From stian at redhat.com  Tue Jan 27 09:49:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 27 Jan 2015 09:49:00 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C7A36F.5070308@redhat.com>
References: <54C15A15.50108@redhat.com> <54C676D0.6010306@redhat.com>
	<54C67C5F.7080708@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
	<54C78DC9.8070304@redhat.com>
	<1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>
	<54C7A36F.5070308@redhat.com>
Message-ID: <1784207783.1375458.1422370140978.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 27, 2015 3:40:47 PM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> Got a little further...Now can't find a Bouncycastle class even though I
> import it everywhere...
> 
> +1000 for putting this off.  This is what I was trying to suggest from
> the beginning.

Oki - so for 1.1.0.Final we'll support loading providers from the file-system only. By default I was thinking we could set it to:

    "providers": [
        "classpath:${jboss.server.config.dir}/providers"
    ]

That means to load providers someone would just put the jars into 'standalone/configuration/providers'.

I'll update docs and examples, with release coming tomorrow or Thursday.

I think we should finish the work with extracting modules and include it in 1.2.0.beta1. I appreciate if you're fed up with it so I can continue the struggle if you'd like..

> 
> On 1/27/2015 9:17 AM, Stian Thorgersen wrote:
> > Does it make sense to hold off on extracting libs into modules and
> > supporting loading providers from modules until after 1.1.0.Final?
> >
> > It may be risky to introduce such a big change just before releasing a
> > final? We can still add support for loading providers from the file-system
> > as that's a much smaller change and only affects custom providers.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, January 27, 2015 2:08:25 PM
> >> Subject: Re: [keycloak-dev] aggregate modules
> >>
> >> Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo in
> >> my persistence.xml file...I'm checking now to see if things work.  I'll
> >> try and implement some aggregate modules after make sure everything works.
> >>
> >> FYI meta-inf="import" doesn't work within a module.xml file, so I
> >> assumed it wouldn't work inside jboss-structure.xml...
> >>
> >> If you don't hear from me, my internet is either down or power is out,
> >> blizzard is here.
> >>
> >> On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
> >>> Had a play with this and I've got an example WAR loading persistence.xml
> >>> from a module working.
> >>>
> >>> To try it on WildFly 8.2.0.Final:
> >>>
> >>> 1. Build and deploy module + war to WildFly
> >>>
> >>> # git clone https://github.com/stianst/playtime.git
> >>> # cd playtime
> >>> # mvn install
> >>> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d
> >>> $JBOSS_HOME
> >>> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war
> >>> $JBOSS_HOME/standalone/deployments/
> >>>
> >>> 2. Start WildFly
> >>>
> >>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "Bill Burke" <bburke at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, January 27, 2015 8:37:09 AM
> >>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>
> >>>> If you commit what you have to a branch I can take a look
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: keycloak-dev at lists.jboss.org
> >>>>> Sent: Monday, January 26, 2015 6:41:51 PM
> >>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>
> >>>>> I also tried this in jboss-deployment-structure.xml
> >>>>>
> >>>>>                <module name="org.keycloak.keycloak-connections-jpa"
> >>>>> services="import">
> >>>>>                    <imports>
> >>>>>                        <include path="META-INF/**"/>
> >>>>>                    </imports>
> >>>>>                </module>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
> >>>>>> Can't find the magic...Keep getting this error:
> >>>>>>
> >>>>>> 12:15:21,803 INFO
> >>>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
> >>>>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml
> >>>>>> file
> >>>>>> in the classpath
> >>>>>>
> >>>>>>
> >>>>>> persistence.xml is in this module:
> >>>>>>
> >>>>>>
> >>>>>> <module xmlns="urn:jboss:module:1.1"
> >>>>>> name="org.keycloak.keycloak-connections-jpa">
> >>>>>>         <resources>
> >>>>>>             <resource-root
> >>>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
> >>>>>>             <!-- Insert resources here -->
> >>>>>>         </resources>
> >>>>>>         <exports>
> >>>>>>             <include path="META-INF/**" />
> >>>>>>         </exports>
> >>>>>>         <dependencies>
> >>>>>>             <module name="org.keycloak.keycloak-core"/>
> >>>>>>             <module name="org.keycloak.keycloak-model-api"/>
> >>>>>>             <module name="javax.persistence.api"/>
> >>>>>>             <module name="org.jboss.logging"/>
> >>>>>>             <module name="javax.api"/>
> >>>>>>             <module name="org.hibernate" services="import">
> >>>>>>                 <imports>
> >>>>>>                 <include path="META-INF/**" />
> >>>>>>             </imports>
> >>>>>>             </module>
> >>>>>>         </dependencies>
> >>>>>>
> >>>>>> </module>
> >>>>>>
> >>>>>>
> >>>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
> >>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
> >>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
> >>>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
> >>>>>>>>>>>> Ran into a wall:
> >>>>>>>>>>>>
> >>>>>>>>>>>> I couldn't have an aggregate module.  service imports didn't
> >>>>>>>>>>>> seem
> >>>>>>>>>>>> to
> >>>>>>>>>>>> work so I had to create a dependency for everything within
> >>>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a
> >>>>>>>>>>>> lot
> >>>>>>>>>>>> of
> >>>>>>>>>>>> errors in my module defintions.
> >>>>>>>>>>> In Brno I can ask David about this.  Can you post your
> >>>>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
> >>>>>>>>>>>> Hibernate
> >>>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
> >>>>>>>>>>>> hibernate
> >>>>>>>>>>>> or
> >>>>>>>>>>>> what.  Tried importing hibernate in various places to no avail.
> >>>>>>>>>>>> Error
> >>>>>>>>>>>> Message isn't very helpful either:
> >>>>>>>>>>>>
> >>>>>>>>>>>> javax.persistence.PersistenceException: No Persistence provider
> >>>>>>>>>>>> for
> >>>>>>>>>>>> EntityManager named keycloak-default
> >>>>>>>>>>> Can you give me a scaled down reproducer for this one?  I can ask
> >>>>>>>>>>> around
> >>>>>>>>>>> and see if anyone knows a solution.
> >>>>>>>>>>
> >>>>>>>>>> I think this is another service import problem.
> >>>>>>>>>
> >>>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
> >>>>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
> >>>>>>>>> https://developer.jboss.org/message/828881#828881
> >>>>>>>>>
> >>>>>>>>> If you're fed up and commit your stuff I can take a look. I've gone
> >>>>>>>>> done
> >>>>>>>>> this in the past so should be able to get it to work again.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Zoinks...I'll try importing META-INF.
> >>>>>>>>
> >>>>>>>> Are we sure we want users dealing with JBoss Modules?
> >>>>>>>
> >>>>>>> Yes ;)
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Bill Burke
> >>>>>>>> JBoss, a division of Red Hat
> >>>>>>>> http://bill.burkecentral.com
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Tue Jan 27 09:58:23 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 27 Jan 2015 09:58:23 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <1784207783.1375458.1422370140978.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com> <54C676D0.6010306@redhat.com>
	<54C67C5F.7080708@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
	<54C78DC9.8070304@redhat.com>
	<1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>
	<54C7A36F.5070308@redhat.com>
	<1784207783.1375458.1422370140978.JavaMail.zimbra@redhat.com>
Message-ID: <54C7A78F.4090708@redhat.com>

I give up, I'm getting:

Caused by: java.lang.NoClassDefFoundError: 
org/bouncycastle/asn1/DEREncodable

 From keycloak-core module, yet the dependency is there...I added 
bouncycastle dependency to every module and jboss-structure.xml and I'm 
still getting this exception.

On 1/27/2015 9:49 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, January 27, 2015 3:40:47 PM
>> Subject: Re: [keycloak-dev] aggregate modules
>>
>> Got a little further...Now can't find a Bouncycastle class even though I
>> import it everywhere...
>>
>> +1000 for putting this off.  This is what I was trying to suggest from
>> the beginning.
>
> Oki - so for 1.1.0.Final we'll support loading providers from the file-system only. By default I was thinking we could set it to:
>
>      "providers": [
>          "classpath:${jboss.server.config.dir}/providers"
>      ]
>
> That means to load providers someone would just put the jars into 'standalone/configuration/providers'.
>
> I'll update docs and examples, with release coming tomorrow or Thursday.
>
> I think we should finish the work with extracting modules and include it in 1.2.0.beta1. I appreciate if you're fed up with it so I can continue the struggle if you'd like..
>
>>
>> On 1/27/2015 9:17 AM, Stian Thorgersen wrote:
>>> Does it make sense to hold off on extracting libs into modules and
>>> supporting loading providers from modules until after 1.1.0.Final?
>>>
>>> It may be risky to introduce such a big change just before releasing a
>>> final? We can still add support for loading providers from the file-system
>>> as that's a much smaller change and only affects custom providers.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, January 27, 2015 2:08:25 PM
>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>
>>>> Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo in
>>>> my persistence.xml file...I'm checking now to see if things work.  I'll
>>>> try and implement some aggregate modules after make sure everything works.
>>>>
>>>> FYI meta-inf="import" doesn't work within a module.xml file, so I
>>>> assumed it wouldn't work inside jboss-structure.xml...
>>>>
>>>> If you don't hear from me, my internet is either down or power is out,
>>>> blizzard is here.
>>>>
>>>> On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
>>>>> Had a play with this and I've got an example WAR loading persistence.xml
>>>>> from a module working.
>>>>>
>>>>> To try it on WildFly 8.2.0.Final:
>>>>>
>>>>> 1. Build and deploy module + war to WildFly
>>>>>
>>>>> # git clone https://github.com/stianst/playtime.git
>>>>> # cd playtime
>>>>> # mvn install
>>>>> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d
>>>>> $JBOSS_HOME
>>>>> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war
>>>>> $JBOSS_HOME/standalone/deployments/
>>>>>
>>>>> 2. Start WildFly
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Tuesday, January 27, 2015 8:37:09 AM
>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>
>>>>>> If you commit what you have to a branch I can take a look
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Monday, January 26, 2015 6:41:51 PM
>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>
>>>>>>> I also tried this in jboss-deployment-structure.xml
>>>>>>>
>>>>>>>                 <module name="org.keycloak.keycloak-connections-jpa"
>>>>>>> services="import">
>>>>>>>                     <imports>
>>>>>>>                         <include path="META-INF/**"/>
>>>>>>>                     </imports>
>>>>>>>                 </module>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
>>>>>>>> Can't find the magic...Keep getting this error:
>>>>>>>>
>>>>>>>> 12:15:21,803 INFO
>>>>>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
>>>>>>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml
>>>>>>>> file
>>>>>>>> in the classpath
>>>>>>>>
>>>>>>>>
>>>>>>>> persistence.xml is in this module:
>>>>>>>>
>>>>>>>>
>>>>>>>> <module xmlns="urn:jboss:module:1.1"
>>>>>>>> name="org.keycloak.keycloak-connections-jpa">
>>>>>>>>          <resources>
>>>>>>>>              <resource-root
>>>>>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
>>>>>>>>              <!-- Insert resources here -->
>>>>>>>>          </resources>
>>>>>>>>          <exports>
>>>>>>>>              <include path="META-INF/**" />
>>>>>>>>          </exports>
>>>>>>>>          <dependencies>
>>>>>>>>              <module name="org.keycloak.keycloak-core"/>
>>>>>>>>              <module name="org.keycloak.keycloak-model-api"/>
>>>>>>>>              <module name="javax.persistence.api"/>
>>>>>>>>              <module name="org.jboss.logging"/>
>>>>>>>>              <module name="javax.api"/>
>>>>>>>>              <module name="org.hibernate" services="import">
>>>>>>>>                  <imports>
>>>>>>>>                  <include path="META-INF/**" />
>>>>>>>>              </imports>
>>>>>>>>              </module>
>>>>>>>>          </dependencies>
>>>>>>>>
>>>>>>>> </module>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>>>>>>>>>> Ran into a wall:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I couldn't have an aggregate module.  service imports didn't
>>>>>>>>>>>>>> seem
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> work so I had to create a dependency for everything within
>>>>>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a
>>>>>>>>>>>>>> lot
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> errors in my module defintions.
>>>>>>>>>>>>> In Brno I can ask David about this.  Can you post your
>>>>>>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
>>>>>>>>>>>>>> Hibernate
>>>>>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
>>>>>>>>>>>>>> hibernate
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> what.  Tried importing hibernate in various places to no avail.
>>>>>>>>>>>>>> Error
>>>>>>>>>>>>>> Message isn't very helpful either:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> javax.persistence.PersistenceException: No Persistence provider
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> EntityManager named keycloak-default
>>>>>>>>>>>>> Can you give me a scaled down reproducer for this one?  I can ask
>>>>>>>>>>>>> around
>>>>>>>>>>>>> and see if anyone knows a solution.
>>>>>>>>>>>>
>>>>>>>>>>>> I think this is another service import problem.
>>>>>>>>>>>
>>>>>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>>>>>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
>>>>>>>>>>> https://developer.jboss.org/message/828881#828881
>>>>>>>>>>>
>>>>>>>>>>> If you're fed up and commit your stuff I can take a look. I've gone
>>>>>>>>>>> done
>>>>>>>>>>> this in the past so should be able to get it to work again.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Zoinks...I'll try importing META-INF.
>>>>>>>>>>
>>>>>>>>>> Are we sure we want users dealing with JBoss Modules?
>>>>>>>>>
>>>>>>>>> Yes ;)
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Bill Burke
>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

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

From gerbermichi at me.com  Tue Jan 27 10:05:14 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 27 Jan 2015 15:05:14 +0000 (GMT)
Subject: [keycloak-dev] Rest password can cause cookie not found
Message-ID: <9a852bab-0b46-4aee-af02-4739d601c0eb@me.com>



Am 27. Januar 2015 um 10:49 schrieb Stian Thorgersen <stian at redhat.com>:



----- Original Message -----
From: "Michael Gerber" <gerbermichi at me.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
Sent: Tuesday, January 27, 2015 10:33:09 AM
Subject: Re: [keycloak-dev] Rest password can cause cookie not found
Am 26. Januar 2015 um 20:49 schrieb Bill Burke <bburke at redhat.com>:
>
>
> On 1/26/2015 1:31 PM, Michael Gerber wrote:
>>> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke at redhat.com
>>>
>>> <mailto:bburke at redhat.com>>:
>>> On 1/26/2015 12:12 PM, Michael Gerber wrote:
>>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com
>>>>>
>>>>> <mailto:bburke at redhat.com>>:
>>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
>>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
>>>>>>> Wouldn't this work?
>>>>>>> 1) store "state" of state cookie in user session.
>>>>>>> 2) embed user session and state of state cookie in URL
>>>>>>> Of course this screws up your "shorter URL" crusade.
>>>>>> I'm not following - the problem isn't remembering the state
>>>>>> variable in Keycloak, that's already sorted as we already store all
>>>>>> the query params passed by the client in the client session (state,
>>>>>> redirect_uri, etc). The problem is storing it on the adapter side.
>>>>> I think I get it...
>>>>> 1. Send email
>>>>> 2. Close browser
>>>>> 3. Open browser
>>>>> 4. Click email link
>>>>> 5. Reset password
>>>>> 6. Redirect back to app
>>>>> 7. App barfs because of state cookie
>>>>> Persistent state cookie sounds like cleanest and simplest solution. I
>>>>> just worry we'll introduce different bugs, or if we're opening up some
>>>>> kind of security hole. Maybe I'm just paranoid.
>>>> That doesn't work if the user uses two different browsers. This is
>>>> the case in a lot of companies (at least in Switzerland :)) where the
>>>> users are forced to use ie (default) but rather work with firefox.
>>> Unless we extend the protocol, or don?t redirect from the email, I
>>> don?t see a fix.
>> If the password reset process would redirect without the code and state
>> param, than the adapter would redirect back to the keycloak, and
>> keycloak can authenticate the user with its identity cookie?
>> But I don?t know if that is ok with the protocol.
>
> So maybe have a session cookie that is set by the auth server. If that
> cookie is set when clicking the email url, redirect with code, if not,
> redirect without it.
>
That sounds good, what do the other think about this fallback option?
I can update the JIRA issue if anybody is happy with th?at solution.

I'm happy with the idea of setting a session cookie so we can detect if a user is using the same browser to complete the flow. However, I don't think we should redirect back to the application.

In this case the user most likely wants to use a different browser for the application. For example a user uses Firefox to open the application, click on recover password, but then due to company policies IE is registered as the default OS browser so links in emails are opened in IE instead. In this case the user wants to close IE after resetting the password and go back to Firefox to use the application.

In the case the user is completing the password reset flow in a different browser it would be better to update the password, make sure no identity cookie or user session is created in the new browser, then just display a message "Your password has been updated".
Why do you want to make sure that no identity cookie is generated??
Wouldn't it be nice to generate the cookie and display a message to the user with a link to the desired redirect uri?
So, the user can still redirect to the uri without a login?

I read that you want to release 1.1.0 Final in the next view days. So I guess this bug/feature will be implemented in 1.2.0?


>
>
> --
> 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/20150127/c76999c8/attachment-0001.html 

From stian at redhat.com  Wed Jan 28 03:27:45 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 Jan 2015 03:27:45 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C7A78F.4090708@redhat.com>
References: <54C15A15.50108@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
	<54C78DC9.8070304@redhat.com>
	<1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>
	<54C7A36F.5070308@redhat.com>
	<1784207783.1375458.1422370140978.JavaMail.zimbra@redhat.com>
	<54C7A78F.4090708@redhat.com>
Message-ID: <1357227901.1985110.1422433665454.JavaMail.zimbra@redhat.com>

I've seen that issue before, it's caused by the version of Bouncycastle included on WildFly. Couldn't figure out why it doesn't work as it has org/bouncycastle/asn1/DEREncodable, but replacing with the version of Bouncycastle we have works.

Once I've released 1.1.0.Final I'll take a look

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 27, 2015 3:58:23 PM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> I give up, I'm getting:
> 
> Caused by: java.lang.NoClassDefFoundError:
> org/bouncycastle/asn1/DEREncodable
> 
>  From keycloak-core module, yet the dependency is there...I added
> bouncycastle dependency to every module and jboss-structure.xml and I'm
> still getting this exception.
> 
> On 1/27/2015 9:49 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, January 27, 2015 3:40:47 PM
> >> Subject: Re: [keycloak-dev] aggregate modules
> >>
> >> Got a little further...Now can't find a Bouncycastle class even though I
> >> import it everywhere...
> >>
> >> +1000 for putting this off.  This is what I was trying to suggest from
> >> the beginning.
> >
> > Oki - so for 1.1.0.Final we'll support loading providers from the
> > file-system only. By default I was thinking we could set it to:
> >
> >      "providers": [
> >          "classpath:${jboss.server.config.dir}/providers"
> >      ]
> >
> > That means to load providers someone would just put the jars into
> > 'standalone/configuration/providers'.
> >
> > I'll update docs and examples, with release coming tomorrow or Thursday.
> >
> > I think we should finish the work with extracting modules and include it in
> > 1.2.0.beta1. I appreciate if you're fed up with it so I can continue the
> > struggle if you'd like..
> >
> >>
> >> On 1/27/2015 9:17 AM, Stian Thorgersen wrote:
> >>> Does it make sense to hold off on extracting libs into modules and
> >>> supporting loading providers from modules until after 1.1.0.Final?
> >>>
> >>> It may be risky to introduce such a big change just before releasing a
> >>> final? We can still add support for loading providers from the
> >>> file-system
> >>> as that's a much smaller change and only affects custom providers.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, January 27, 2015 2:08:25 PM
> >>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>
> >>>> Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo in
> >>>> my persistence.xml file...I'm checking now to see if things work.  I'll
> >>>> try and implement some aggregate modules after make sure everything
> >>>> works.
> >>>>
> >>>> FYI meta-inf="import" doesn't work within a module.xml file, so I
> >>>> assumed it wouldn't work inside jboss-structure.xml...
> >>>>
> >>>> If you don't hear from me, my internet is either down or power is out,
> >>>> blizzard is here.
> >>>>
> >>>> On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
> >>>>> Had a play with this and I've got an example WAR loading
> >>>>> persistence.xml
> >>>>> from a module working.
> >>>>>
> >>>>> To try it on WildFly 8.2.0.Final:
> >>>>>
> >>>>> 1. Build and deploy module + war to WildFly
> >>>>>
> >>>>> # git clone https://github.com/stianst/playtime.git
> >>>>> # cd playtime
> >>>>> # mvn install
> >>>>> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d
> >>>>> $JBOSS_HOME
> >>>>> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war
> >>>>> $JBOSS_HOME/standalone/deployments/
> >>>>>
> >>>>> 2. Start WildFly
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> To: "Bill Burke" <bburke at redhat.com>
> >>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Tuesday, January 27, 2015 8:37:09 AM
> >>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>
> >>>>>> If you commit what you have to a branch I can take a look
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Monday, January 26, 2015 6:41:51 PM
> >>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>
> >>>>>>> I also tried this in jboss-deployment-structure.xml
> >>>>>>>
> >>>>>>>                 <module name="org.keycloak.keycloak-connections-jpa"
> >>>>>>> services="import">
> >>>>>>>                     <imports>
> >>>>>>>                         <include path="META-INF/**"/>
> >>>>>>>                     </imports>
> >>>>>>>                 </module>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
> >>>>>>>> Can't find the magic...Keep getting this error:
> >>>>>>>>
> >>>>>>>> 12:15:21,803 INFO
> >>>>>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
> >>>>>>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml
> >>>>>>>> file
> >>>>>>>> in the classpath
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> persistence.xml is in this module:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> <module xmlns="urn:jboss:module:1.1"
> >>>>>>>> name="org.keycloak.keycloak-connections-jpa">
> >>>>>>>>          <resources>
> >>>>>>>>              <resource-root
> >>>>>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
> >>>>>>>>              <!-- Insert resources here -->
> >>>>>>>>          </resources>
> >>>>>>>>          <exports>
> >>>>>>>>              <include path="META-INF/**" />
> >>>>>>>>          </exports>
> >>>>>>>>          <dependencies>
> >>>>>>>>              <module name="org.keycloak.keycloak-core"/>
> >>>>>>>>              <module name="org.keycloak.keycloak-model-api"/>
> >>>>>>>>              <module name="javax.persistence.api"/>
> >>>>>>>>              <module name="org.jboss.logging"/>
> >>>>>>>>              <module name="javax.api"/>
> >>>>>>>>              <module name="org.hibernate" services="import">
> >>>>>>>>                  <imports>
> >>>>>>>>                  <include path="META-INF/**" />
> >>>>>>>>              </imports>
> >>>>>>>>              </module>
> >>>>>>>>          </dependencies>
> >>>>>>>>
> >>>>>>>> </module>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
> >>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
> >>>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
> >>>>>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
> >>>>>>>>>>>>>> Ran into a wall:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I couldn't have an aggregate module.  service imports didn't
> >>>>>>>>>>>>>> seem
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>> work so I had to create a dependency for everything within
> >>>>>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a
> >>>>>>>>>>>>>> lot
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>> errors in my module defintions.
> >>>>>>>>>>>>> In Brno I can ask David about this.  Can you post your
> >>>>>>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
> >>>>>>>>>>>>>> Hibernate
> >>>>>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
> >>>>>>>>>>>>>> hibernate
> >>>>>>>>>>>>>> or
> >>>>>>>>>>>>>> what.  Tried importing hibernate in various places to no
> >>>>>>>>>>>>>> avail.
> >>>>>>>>>>>>>> Error
> >>>>>>>>>>>>>> Message isn't very helpful either:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> javax.persistence.PersistenceException: No Persistence
> >>>>>>>>>>>>>> provider
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>> EntityManager named keycloak-default
> >>>>>>>>>>>>> Can you give me a scaled down reproducer for this one?  I can
> >>>>>>>>>>>>> ask
> >>>>>>>>>>>>> around
> >>>>>>>>>>>>> and see if anyone knows a solution.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think this is another service import problem.
> >>>>>>>>>>>
> >>>>>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
> >>>>>>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
> >>>>>>>>>>> https://developer.jboss.org/message/828881#828881
> >>>>>>>>>>>
> >>>>>>>>>>> If you're fed up and commit your stuff I can take a look. I've
> >>>>>>>>>>> gone
> >>>>>>>>>>> done
> >>>>>>>>>>> this in the past so should be able to get it to work again.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Zoinks...I'll try importing META-INF.
> >>>>>>>>>>
> >>>>>>>>>> Are we sure we want users dealing with JBoss Modules?
> >>>>>>>>>
> >>>>>>>>> Yes ;)
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Bill Burke
> >>>>>>>>>> JBoss, a division of Red Hat
> >>>>>>>>>> http://bill.burkecentral.com
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Wed Jan 28 09:01:08 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 Jan 2015 09:01:08 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <1357227901.1985110.1422433665454.JavaMail.zimbra@redhat.com>
References: <54C15A15.50108@redhat.com>
	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>
	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>
	<54C78DC9.8070304@redhat.com>
	<1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>
	<54C7A36F.5070308@redhat.com>
	<1784207783.1375458.1422370140978.JavaMail.zimbra@redhat.com>
	<54C7A78F.4090708@redhat.com>
	<1357227901.1985110.1422433665454.JavaMail.zimbra@redhat.com>
Message-ID: <54C8EBA4.7090707@redhat.com>

Wonder if jar signing have any effect on class resolving

On 1/28/2015 3:27 AM, Stian Thorgersen wrote:
> I've seen that issue before, it's caused by the version of Bouncycastle included on WildFly. Couldn't figure out why it doesn't work as it has org/bouncycastle/asn1/DEREncodable, but replacing with the version of Bouncycastle we have works.
>
> Once I've released 1.1.0.Final I'll take a look
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, January 27, 2015 3:58:23 PM
>> Subject: Re: [keycloak-dev] aggregate modules
>>
>> I give up, I'm getting:
>>
>> Caused by: java.lang.NoClassDefFoundError:
>> org/bouncycastle/asn1/DEREncodable
>>
>>   From keycloak-core module, yet the dependency is there...I added
>> bouncycastle dependency to every module and jboss-structure.xml and I'm
>> still getting this exception.
>>
>> On 1/27/2015 9:49 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, January 27, 2015 3:40:47 PM
>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>
>>>> Got a little further...Now can't find a Bouncycastle class even though I
>>>> import it everywhere...
>>>>
>>>> +1000 for putting this off.  This is what I was trying to suggest from
>>>> the beginning.
>>>
>>> Oki - so for 1.1.0.Final we'll support loading providers from the
>>> file-system only. By default I was thinking we could set it to:
>>>
>>>       "providers": [
>>>           "classpath:${jboss.server.config.dir}/providers"
>>>       ]
>>>
>>> That means to load providers someone would just put the jars into
>>> 'standalone/configuration/providers'.
>>>
>>> I'll update docs and examples, with release coming tomorrow or Thursday.
>>>
>>> I think we should finish the work with extracting modules and include it in
>>> 1.2.0.beta1. I appreciate if you're fed up with it so I can continue the
>>> struggle if you'd like..
>>>
>>>>
>>>> On 1/27/2015 9:17 AM, Stian Thorgersen wrote:
>>>>> Does it make sense to hold off on extracting libs into modules and
>>>>> supporting loading providers from modules until after 1.1.0.Final?
>>>>>
>>>>> It may be risky to introduce such a big change just before releasing a
>>>>> final? We can still add support for loading providers from the
>>>>> file-system
>>>>> as that's a much smaller change and only affects custom providers.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Tuesday, January 27, 2015 2:08:25 PM
>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>
>>>>>> Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo in
>>>>>> my persistence.xml file...I'm checking now to see if things work.  I'll
>>>>>> try and implement some aggregate modules after make sure everything
>>>>>> works.
>>>>>>
>>>>>> FYI meta-inf="import" doesn't work within a module.xml file, so I
>>>>>> assumed it wouldn't work inside jboss-structure.xml...
>>>>>>
>>>>>> If you don't hear from me, my internet is either down or power is out,
>>>>>> blizzard is here.
>>>>>>
>>>>>> On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
>>>>>>> Had a play with this and I've got an example WAR loading
>>>>>>> persistence.xml
>>>>>>> from a module working.
>>>>>>>
>>>>>>> To try it on WildFly 8.2.0.Final:
>>>>>>>
>>>>>>> 1. Build and deploy module + war to WildFly
>>>>>>>
>>>>>>> # git clone https://github.com/stianst/playtime.git
>>>>>>> # cd playtime
>>>>>>> # mvn install
>>>>>>> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d
>>>>>>> $JBOSS_HOME
>>>>>>> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war
>>>>>>> $JBOSS_HOME/standalone/deployments/
>>>>>>>
>>>>>>> 2. Start WildFly
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Tuesday, January 27, 2015 8:37:09 AM
>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>
>>>>>>>> If you commit what you have to a branch I can take a look
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Monday, January 26, 2015 6:41:51 PM
>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>
>>>>>>>>> I also tried this in jboss-deployment-structure.xml
>>>>>>>>>
>>>>>>>>>                  <module name="org.keycloak.keycloak-connections-jpa"
>>>>>>>>> services="import">
>>>>>>>>>                      <imports>
>>>>>>>>>                          <include path="META-INF/**"/>
>>>>>>>>>                      </imports>
>>>>>>>>>                  </module>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
>>>>>>>>>> Can't find the magic...Keep getting this error:
>>>>>>>>>>
>>>>>>>>>> 12:15:21,803 INFO
>>>>>>>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
>>>>>>>>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml
>>>>>>>>>> file
>>>>>>>>>> in the classpath
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> persistence.xml is in this module:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <module xmlns="urn:jboss:module:1.1"
>>>>>>>>>> name="org.keycloak.keycloak-connections-jpa">
>>>>>>>>>>           <resources>
>>>>>>>>>>               <resource-root
>>>>>>>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
>>>>>>>>>>               <!-- Insert resources here -->
>>>>>>>>>>           </resources>
>>>>>>>>>>           <exports>
>>>>>>>>>>               <include path="META-INF/**" />
>>>>>>>>>>           </exports>
>>>>>>>>>>           <dependencies>
>>>>>>>>>>               <module name="org.keycloak.keycloak-core"/>
>>>>>>>>>>               <module name="org.keycloak.keycloak-model-api"/>
>>>>>>>>>>               <module name="javax.persistence.api"/>
>>>>>>>>>>               <module name="org.jboss.logging"/>
>>>>>>>>>>               <module name="javax.api"/>
>>>>>>>>>>               <module name="org.hibernate" services="import">
>>>>>>>>>>                   <imports>
>>>>>>>>>>                   <include path="META-INF/**" />
>>>>>>>>>>               </imports>
>>>>>>>>>>               </module>
>>>>>>>>>>           </dependencies>
>>>>>>>>>>
>>>>>>>>>> </module>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
>>>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>>>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>>>>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>>>>>>>>>>>> Ran into a wall:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I couldn't have an aggregate module.  service imports didn't
>>>>>>>>>>>>>>>> seem
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> work so I had to create a dependency for everything within
>>>>>>>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a
>>>>>>>>>>>>>>>> lot
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> errors in my module defintions.
>>>>>>>>>>>>>>> In Brno I can ask David about this.  Can you post your
>>>>>>>>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
>>>>>>>>>>>>>>>> Hibernate
>>>>>>>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
>>>>>>>>>>>>>>>> hibernate
>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>> what.  Tried importing hibernate in various places to no
>>>>>>>>>>>>>>>> avail.
>>>>>>>>>>>>>>>> Error
>>>>>>>>>>>>>>>> Message isn't very helpful either:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> javax.persistence.PersistenceException: No Persistence
>>>>>>>>>>>>>>>> provider
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> EntityManager named keycloak-default
>>>>>>>>>>>>>>> Can you give me a scaled down reproducer for this one?  I can
>>>>>>>>>>>>>>> ask
>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>> and see if anyone knows a solution.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think this is another service import problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>>>>>>>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
>>>>>>>>>>>>> https://developer.jboss.org/message/828881#828881
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you're fed up and commit your stuff I can take a look. I've
>>>>>>>>>>>>> gone
>>>>>>>>>>>>> done
>>>>>>>>>>>>> this in the past so should be able to get it to work again.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Zoinks...I'll try importing META-INF.
>>>>>>>>>>>>
>>>>>>>>>>>> Are we sure we want users dealing with JBoss Modules?
>>>>>>>>>>>
>>>>>>>>>>> Yes ;)
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Bill Burke
>>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

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

From bburke at redhat.com  Wed Jan 28 09:30:48 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 Jan 2015 09:30:48 -0500
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C8EBA4.7090707@redhat.com>
References: <54C15A15.50108@redhat.com>	<774846310.846330.1422344229324.JavaMail.zimbra@redhat.com>	<1881905376.1059776.1422356608274.JavaMail.zimbra@redhat.com>	<54C78DC9.8070304@redhat.com>	<1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>	<54C7A36F.5070308@redhat.com>	<1784207783.1375458.1422370140978.JavaMail.zimbra@redhat.com>	<54C7A78F.4090708@redhat.com>	<1357227901.1985110.1422433665454.JavaMail.zimbra@redhat.com>
	<54C8EBA4.7090707@redhat.com>
Message-ID: <54C8F298.8030106@redhat.com>

That was it BTW...There's still more CNF errors though that would need 
to be resolved.

Also, we'd have to edit all our poms to sync with Wildfly 8.2, and/or 
maybe even have different distros per JBoss/Wildfly version :(

On 1/28/2015 9:01 AM, Bill Burke wrote:
> Wonder if jar signing have any effect on class resolving
>
> On 1/28/2015 3:27 AM, Stian Thorgersen wrote:
>> I've seen that issue before, it's caused by the version of Bouncycastle included on WildFly. Couldn't figure out why it doesn't work as it has org/bouncycastle/asn1/DEREncodable, but replacing with the version of Bouncycastle we have works.
>>
>> Once I've released 1.1.0.Final I'll take a look
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, January 27, 2015 3:58:23 PM
>>> Subject: Re: [keycloak-dev] aggregate modules
>>>
>>> I give up, I'm getting:
>>>
>>> Caused by: java.lang.NoClassDefFoundError:
>>> org/bouncycastle/asn1/DEREncodable
>>>
>>>    From keycloak-core module, yet the dependency is there...I added
>>> bouncycastle dependency to every module and jboss-structure.xml and I'm
>>> still getting this exception.
>>>
>>> On 1/27/2015 9:49 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Tuesday, January 27, 2015 3:40:47 PM
>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>
>>>>> Got a little further...Now can't find a Bouncycastle class even though I
>>>>> import it everywhere...
>>>>>
>>>>> +1000 for putting this off.  This is what I was trying to suggest from
>>>>> the beginning.
>>>>
>>>> Oki - so for 1.1.0.Final we'll support loading providers from the
>>>> file-system only. By default I was thinking we could set it to:
>>>>
>>>>        "providers": [
>>>>            "classpath:${jboss.server.config.dir}/providers"
>>>>        ]
>>>>
>>>> That means to load providers someone would just put the jars into
>>>> 'standalone/configuration/providers'.
>>>>
>>>> I'll update docs and examples, with release coming tomorrow or Thursday.
>>>>
>>>> I think we should finish the work with extracting modules and include it in
>>>> 1.2.0.beta1. I appreciate if you're fed up with it so I can continue the
>>>> struggle if you'd like..
>>>>
>>>>>
>>>>> On 1/27/2015 9:17 AM, Stian Thorgersen wrote:
>>>>>> Does it make sense to hold off on extracting libs into modules and
>>>>>> supporting loading providers from modules until after 1.1.0.Final?
>>>>>>
>>>>>> It may be risky to introduce such a big change just before releasing a
>>>>>> final? We can still add support for loading providers from the
>>>>>> file-system
>>>>>> as that's a much smaller change and only affects custom providers.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Tuesday, January 27, 2015 2:08:25 PM
>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>
>>>>>>> Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo in
>>>>>>> my persistence.xml file...I'm checking now to see if things work.  I'll
>>>>>>> try and implement some aggregate modules after make sure everything
>>>>>>> works.
>>>>>>>
>>>>>>> FYI meta-inf="import" doesn't work within a module.xml file, so I
>>>>>>> assumed it wouldn't work inside jboss-structure.xml...
>>>>>>>
>>>>>>> If you don't hear from me, my internet is either down or power is out,
>>>>>>> blizzard is here.
>>>>>>>
>>>>>>> On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
>>>>>>>> Had a play with this and I've got an example WAR loading
>>>>>>>> persistence.xml
>>>>>>>> from a module working.
>>>>>>>>
>>>>>>>> To try it on WildFly 8.2.0.Final:
>>>>>>>>
>>>>>>>> 1. Build and deploy module + war to WildFly
>>>>>>>>
>>>>>>>> # git clone https://github.com/stianst/playtime.git
>>>>>>>> # cd playtime
>>>>>>>> # mvn install
>>>>>>>> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d
>>>>>>>> $JBOSS_HOME
>>>>>>>> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war
>>>>>>>> $JBOSS_HOME/standalone/deployments/
>>>>>>>>
>>>>>>>> 2. Start WildFly
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Tuesday, January 27, 2015 8:37:09 AM
>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>
>>>>>>>>> If you commit what you have to a branch I can take a look
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>>> Sent: Monday, January 26, 2015 6:41:51 PM
>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>>
>>>>>>>>>> I also tried this in jboss-deployment-structure.xml
>>>>>>>>>>
>>>>>>>>>>                   <module name="org.keycloak.keycloak-connections-jpa"
>>>>>>>>>> services="import">
>>>>>>>>>>                       <imports>
>>>>>>>>>>                           <include path="META-INF/**"/>
>>>>>>>>>>                       </imports>
>>>>>>>>>>                   </module>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
>>>>>>>>>>> Can't find the magic...Keep getting this error:
>>>>>>>>>>>
>>>>>>>>>>> 12:15:21,803 INFO
>>>>>>>>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC service
>>>>>>>>>>> thread 1-7) HHH000318: Could not find any META-INF/persistence.xml
>>>>>>>>>>> file
>>>>>>>>>>> in the classpath
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> persistence.xml is in this module:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <module xmlns="urn:jboss:module:1.1"
>>>>>>>>>>> name="org.keycloak.keycloak-connections-jpa">
>>>>>>>>>>>            <resources>
>>>>>>>>>>>                <resource-root
>>>>>>>>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
>>>>>>>>>>>                <!-- Insert resources here -->
>>>>>>>>>>>            </resources>
>>>>>>>>>>>            <exports>
>>>>>>>>>>>                <include path="META-INF/**" />
>>>>>>>>>>>            </exports>
>>>>>>>>>>>            <dependencies>
>>>>>>>>>>>                <module name="org.keycloak.keycloak-core"/>
>>>>>>>>>>>                <module name="org.keycloak.keycloak-model-api"/>
>>>>>>>>>>>                <module name="javax.persistence.api"/>
>>>>>>>>>>>                <module name="org.jboss.logging"/>
>>>>>>>>>>>                <module name="javax.api"/>
>>>>>>>>>>>                <module name="org.hibernate" services="import">
>>>>>>>>>>>                    <imports>
>>>>>>>>>>>                    <include path="META-INF/**" />
>>>>>>>>>>>                </imports>
>>>>>>>>>>>                </module>
>>>>>>>>>>>            </dependencies>
>>>>>>>>>>>
>>>>>>>>>>> </module>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
>>>>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
>>>>>>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
>>>>>>>>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
>>>>>>>>>>>>>>>>> Ran into a wall:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I couldn't have an aggregate module.  service imports didn't
>>>>>>>>>>>>>>>>> seem
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> work so I had to create a dependency for everything within
>>>>>>>>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I had a
>>>>>>>>>>>>>>>>> lot
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> errors in my module defintions.
>>>>>>>>>>>>>>>> In Brno I can ask David about this.  Can you post your
>>>>>>>>>>>>>>>> jboss-deployment-structure.xml and your aggregate module.xml?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
>>>>>>>>>>>>>>>>> Hibernate
>>>>>>>>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
>>>>>>>>>>>>>>>>> hibernate
>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>> what.  Tried importing hibernate in various places to no
>>>>>>>>>>>>>>>>> avail.
>>>>>>>>>>>>>>>>> Error
>>>>>>>>>>>>>>>>> Message isn't very helpful either:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> javax.persistence.PersistenceException: No Persistence
>>>>>>>>>>>>>>>>> provider
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> EntityManager named keycloak-default
>>>>>>>>>>>>>>>> Can you give me a scaled down reproducer for this one?  I can
>>>>>>>>>>>>>>>> ask
>>>>>>>>>>>>>>>> around
>>>>>>>>>>>>>>>> and see if anyone knows a solution.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think this is another service import problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
>>>>>>>>>>>>>> META-INF/persistence.xml isn't exported/imported by default, see
>>>>>>>>>>>>>> https://developer.jboss.org/message/828881#828881
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you're fed up and commit your stuff I can take a look. I've
>>>>>>>>>>>>>> gone
>>>>>>>>>>>>>> done
>>>>>>>>>>>>>> this in the past so should be able to get it to work again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Zoinks...I'll try importing META-INF.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are we sure we want users dealing with JBoss Modules?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes ;)
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Bill Burke
>>>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>

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

From stian at redhat.com  Wed Jan 28 09:44:17 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 28 Jan 2015 09:44:17 -0500 (EST)
Subject: [keycloak-dev] aggregate modules
In-Reply-To: <54C8F298.8030106@redhat.com>
References: <54C15A15.50108@redhat.com>
	<1565454307.1350201.1422368227007.JavaMail.zimbra@redhat.com>
	<54C7A36F.5070308@redhat.com>
	<1784207783.1375458.1422370140978.JavaMail.zimbra@redhat.com>
	<54C7A78F.4090708@redhat.com>
	<1357227901.1985110.1422433665454.JavaMail.zimbra@redhat.com>
	<54C8EBA4.7090707@redhat.com> <54C8F298.8030106@redhat.com>
Message-ID: <213686668.2220206.1422456257442.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, January 28, 2015 3:30:48 PM
> Subject: Re: [keycloak-dev] aggregate modules
> 
> That was it BTW...There's still more CNF errors though that would need
> to be resolved.
> 
> Also, we'd have to edit all our poms to sync with Wildfly 8.2, and/or
> maybe even have different distros per JBoss/Wildfly version :(

Why is that required? 

For libraries we add it doesn't make any difference whether we include it in WEB-INF/lib or add it as a module. For libraries we depend on from WildFly we need to make sure the version matches any ways.

With regards to dist maybe we should have:

* Standalone server - bundle that includes latest WildFly
* Overlay - zip that can be exploded into an existing WildFly or EAP. We may have to have different overlay downloads for each EAP version we support as well as WildFly

Projects that want to embed Keycloak can probably use the overlay.

> 
> On 1/28/2015 9:01 AM, Bill Burke wrote:
> > Wonder if jar signing have any effect on class resolving
> >
> > On 1/28/2015 3:27 AM, Stian Thorgersen wrote:
> >> I've seen that issue before, it's caused by the version of Bouncycastle
> >> included on WildFly. Couldn't figure out why it doesn't work as it has
> >> org/bouncycastle/asn1/DEREncodable, but replacing with the version of
> >> Bouncycastle we have works.
> >>
> >> Once I've released 1.1.0.Final I'll take a look
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Stian Thorgersen" <stian at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, January 27, 2015 3:58:23 PM
> >>> Subject: Re: [keycloak-dev] aggregate modules
> >>>
> >>> I give up, I'm getting:
> >>>
> >>> Caused by: java.lang.NoClassDefFoundError:
> >>> org/bouncycastle/asn1/DEREncodable
> >>>
> >>>    From keycloak-core module, yet the dependency is there...I added
> >>> bouncycastle dependency to every module and jboss-structure.xml and I'm
> >>> still getting this exception.
> >>>
> >>> On 1/27/2015 9:49 AM, Stian Thorgersen wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Tuesday, January 27, 2015 3:40:47 PM
> >>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>
> >>>>> Got a little further...Now can't find a Bouncycastle class even though
> >>>>> I
> >>>>> import it everywhere...
> >>>>>
> >>>>> +1000 for putting this off.  This is what I was trying to suggest from
> >>>>> the beginning.
> >>>>
> >>>> Oki - so for 1.1.0.Final we'll support loading providers from the
> >>>> file-system only. By default I was thinking we could set it to:
> >>>>
> >>>>        "providers": [
> >>>>            "classpath:${jboss.server.config.dir}/providers"
> >>>>        ]
> >>>>
> >>>> That means to load providers someone would just put the jars into
> >>>> 'standalone/configuration/providers'.
> >>>>
> >>>> I'll update docs and examples, with release coming tomorrow or Thursday.
> >>>>
> >>>> I think we should finish the work with extracting modules and include it
> >>>> in
> >>>> 1.2.0.beta1. I appreciate if you're fed up with it so I can continue the
> >>>> struggle if you'd like..
> >>>>
> >>>>>
> >>>>> On 1/27/2015 9:17 AM, Stian Thorgersen wrote:
> >>>>>> Does it make sense to hold off on extracting libs into modules and
> >>>>>> supporting loading providers from modules until after 1.1.0.Final?
> >>>>>>
> >>>>>> It may be risky to introduce such a big change just before releasing a
> >>>>>> final? We can still add support for loading providers from the
> >>>>>> file-system
> >>>>>> as that's a much smaller change and only affects custom providers.
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Tuesday, January 27, 2015 2:08:25 PM
> >>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>
> >>>>>>> Ok, it was meta-inf="import within jboss-structure.xml.  I had a typo
> >>>>>>> in
> >>>>>>> my persistence.xml file...I'm checking now to see if things work.
> >>>>>>> I'll
> >>>>>>> try and implement some aggregate modules after make sure everything
> >>>>>>> works.
> >>>>>>>
> >>>>>>> FYI meta-inf="import" doesn't work within a module.xml file, so I
> >>>>>>> assumed it wouldn't work inside jboss-structure.xml...
> >>>>>>>
> >>>>>>> If you don't hear from me, my internet is either down or power is
> >>>>>>> out,
> >>>>>>> blizzard is here.
> >>>>>>>
> >>>>>>> On 1/27/2015 6:03 AM, Stian Thorgersen wrote:
> >>>>>>>> Had a play with this and I've got an example WAR loading
> >>>>>>>> persistence.xml
> >>>>>>>> from a module working.
> >>>>>>>>
> >>>>>>>> To try it on WildFly 8.2.0.Final:
> >>>>>>>>
> >>>>>>>> 1. Build and deploy module + war to WildFly
> >>>>>>>>
> >>>>>>>> # git clone https://github.com/stianst/playtime.git
> >>>>>>>> # cd playtime
> >>>>>>>> # mvn install
> >>>>>>>> # unzip jpa-jar/target/playtime-jpa-jar-1-SNAPSHOT-module.zip -d
> >>>>>>>> $JBOSS_HOME
> >>>>>>>> # cp jpa/target/playtime-jpa-1-SNAPSHOT.war
> >>>>>>>> $JBOSS_HOME/standalone/deployments/
> >>>>>>>>
> >>>>>>>> 2. Start WildFly
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>>>> To: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Tuesday, January 27, 2015 8:37:09 AM
> >>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>>
> >>>>>>>>> If you commit what you have to a branch I can take a look
> >>>>>>>>>
> >>>>>>>>> ----- Original Message -----
> >>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>>> Sent: Monday, January 26, 2015 6:41:51 PM
> >>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>>>
> >>>>>>>>>> I also tried this in jboss-deployment-structure.xml
> >>>>>>>>>>
> >>>>>>>>>>                   <module
> >>>>>>>>>>                   name="org.keycloak.keycloak-connections-jpa"
> >>>>>>>>>> services="import">
> >>>>>>>>>>                       <imports>
> >>>>>>>>>>                           <include path="META-INF/**"/>
> >>>>>>>>>>                       </imports>
> >>>>>>>>>>                   </module>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 1/26/2015 12:18 PM, Bill Burke wrote:
> >>>>>>>>>>> Can't find the magic...Keep getting this error:
> >>>>>>>>>>>
> >>>>>>>>>>> 12:15:21,803 INFO
> >>>>>>>>>>> [org.hibernate.jpa.boot.internal.PersistenceXmlParser] (MSC
> >>>>>>>>>>> service
> >>>>>>>>>>> thread 1-7) HHH000318: Could not find any
> >>>>>>>>>>> META-INF/persistence.xml
> >>>>>>>>>>> file
> >>>>>>>>>>> in the classpath
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> persistence.xml is in this module:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> <module xmlns="urn:jboss:module:1.1"
> >>>>>>>>>>> name="org.keycloak.keycloak-connections-jpa">
> >>>>>>>>>>>            <resources>
> >>>>>>>>>>>                <resource-root
> >>>>>>>>>>> path="keycloak-connections-jpa-1.1.0.Final-SNAPSHOT.jar"/>
> >>>>>>>>>>>                <!-- Insert resources here -->
> >>>>>>>>>>>            </resources>
> >>>>>>>>>>>            <exports>
> >>>>>>>>>>>                <include path="META-INF/**" />
> >>>>>>>>>>>            </exports>
> >>>>>>>>>>>            <dependencies>
> >>>>>>>>>>>                <module name="org.keycloak.keycloak-core"/>
> >>>>>>>>>>>                <module name="org.keycloak.keycloak-model-api"/>
> >>>>>>>>>>>                <module name="javax.persistence.api"/>
> >>>>>>>>>>>                <module name="org.jboss.logging"/>
> >>>>>>>>>>>                <module name="javax.api"/>
> >>>>>>>>>>>                <module name="org.hibernate" services="import">
> >>>>>>>>>>>                    <imports>
> >>>>>>>>>>>                    <include path="META-INF/**" />
> >>>>>>>>>>>                </imports>
> >>>>>>>>>>>                </module>
> >>>>>>>>>>>            </dependencies>
> >>>>>>>>>>>
> >>>>>>>>>>> </module>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 1/26/2015 7:26 AM, Stian Thorgersen wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>>>>>>>> Sent: Monday, January 26, 2015 1:17:21 PM
> >>>>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 1/26/2015 2:43 AM, Stian Thorgersen wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>>>>>>>> Sent: Monday, January 26, 2015 3:03:40 AM
> >>>>>>>>>>>>>>> Subject: Re: [keycloak-dev] aggregate modules
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 1/24/2015 7:00 AM, Stan Silvert wrote:
> >>>>>>>>>>>>>>>> On 1/23/2015 5:53 PM, Bill Burke wrote:
> >>>>>>>>>>>>>>>>> Ran into a wall:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I couldn't have an aggregate module.  service imports
> >>>>>>>>>>>>>>>>> didn't
> >>>>>>>>>>>>>>>>> seem
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> work so I had to create a dependency for everything within
> >>>>>>>>>>>>>>>>> jboss-deployment-structure.xml.  I may revisit this as I
> >>>>>>>>>>>>>>>>> had a
> >>>>>>>>>>>>>>>>> lot
> >>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>> errors in my module defintions.
> >>>>>>>>>>>>>>>> In Brno I can ask David about this.  Can you post your
> >>>>>>>>>>>>>>>> jboss-deployment-structure.xml and your aggregate
> >>>>>>>>>>>>>>>> module.xml?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I'm at a wall.  I can't get the JPA connections to find the
> >>>>>>>>>>>>>>>>> Hibernate
> >>>>>>>>>>>>>>>>> provider.  I"m not sure if it can't find persistence.xml or
> >>>>>>>>>>>>>>>>> hibernate
> >>>>>>>>>>>>>>>>> or
> >>>>>>>>>>>>>>>>> what.  Tried importing hibernate in various places to no
> >>>>>>>>>>>>>>>>> avail.
> >>>>>>>>>>>>>>>>> Error
> >>>>>>>>>>>>>>>>> Message isn't very helpful either:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> javax.persistence.PersistenceException: No Persistence
> >>>>>>>>>>>>>>>>> provider
> >>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>> EntityManager named keycloak-default
> >>>>>>>>>>>>>>>> Can you give me a scaled down reproducer for this one?  I
> >>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>> ask
> >>>>>>>>>>>>>>>> around
> >>>>>>>>>>>>>>>> and see if anyone knows a solution.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think this is another service import problem.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Loading JPA in this way will work, but it's a bit of a PITA.
> >>>>>>>>>>>>>> META-INF/persistence.xml isn't exported/imported by default,
> >>>>>>>>>>>>>> see
> >>>>>>>>>>>>>> https://developer.jboss.org/message/828881#828881
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If you're fed up and commit your stuff I can take a look. I've
> >>>>>>>>>>>>>> gone
> >>>>>>>>>>>>>> done
> >>>>>>>>>>>>>> this in the past so should be able to get it to work again.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Zoinks...I'll try importing META-INF.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Are we sure we want users dealing with JBoss Modules?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Yes ;)
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Bill Burke
> >>>>>>>>>>>>> JBoss, a division of Red Hat
> >>>>>>>>>>>>> http://bill.burkecentral.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> 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
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> Bill Burke
> >>>>> JBoss, a division of Red Hat
> >>>>> http://bill.burkecentral.com
> >>>>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>>
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From nicholas at monstersoftwarellc.com  Wed Jan 28 13:15:20 2015
From: nicholas at monstersoftwarellc.com (Nicholas Padilla)
Date: Wed, 28 Jan 2015 11:15:20 -0700
Subject: [keycloak-dev] Keycloak 1.1.0.Final Admin Console Refresh every 5sec
Message-ID: <CAKBbQsi0mfz2Qfz6RGjoMzLfWZQ2zN59y9V60FMn=N-OPee6fg@mail.gmail.com>

Hello All,

I have just downloaded the 1.1.0.Final release and found that every 5
seconds the admin console browser page refreshes.  This is, I think,
preventing me from adding my realm.json export file. I am
using keycloak-appliance-dist-all-1.1.0.Final.  Please advise.

As a side note, I was trying to see if the 1.1.0.Final release correctly
handled the KEYCLOAK_RESOURCE role added to the Oauth Client for one of my
realms.  Since the usage of this client is trusted, so want to not have to
grant access to the resources every time for the client.  There is nothing
in the documentation on how to set that up, only in the Login Algorithm
page on the github wiki. Please advise as how to use this feature.

Thanks!

Nicholas Padilla
www.monstersoftwarellc.com

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

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

From stian at redhat.com  Thu Jan 29 02:11:26 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 Jan 2015 02:11:26 -0500 (EST)
Subject: [keycloak-dev] Keycloak 1.1.0.Final Released
Message-ID: <282508176.2775455.1422515486824.JavaMail.zimbra@redhat.com>

The Keycloak team is proud to announce the release of Keycloak 1.1.0.Final. Highlights in this release includes:

* SAML 2.0
* Clustering
* Jetty, Tomcat and Fuse adapters
* HTTP Security Proxy
* Automatic migration of db schema

We?re already started working on features for the next release. Some exiting features coming soon includes:

* Identity brokering
* Custom user profiles
* Kerberos
* OpenID Connect interop


From stian at redhat.com  Thu Jan 29 02:15:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 Jan 2015 02:15:07 -0500 (EST)
Subject: [keycloak-dev] Keycloak 1.1.0.Final Admin Console Refresh every
 5sec
In-Reply-To: <CAKBbQsi0mfz2Qfz6RGjoMzLfWZQ2zN59y9V60FMn=N-OPee6fg@mail.gmail.com>
References: <CAKBbQsi0mfz2Qfz6RGjoMzLfWZQ2zN59y9V60FMn=N-OPee6fg@mail.gmail.com>
Message-ID: <972562206.2776801.1422515707137.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Nicholas Padilla" <nicholas at monstersoftwarellc.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, January 28, 2015 7:15:20 PM
> Subject: [keycloak-dev] Keycloak 1.1.0.Final Admin Console Refresh every 5sec
> 
> Hello All,
> 
> I have just downloaded the 1.1.0.Final release and found that every 5 seconds
> the admin console browser page refreshes. This is, I think, preventing me
> from adding my realm.json export file. I am using
> keycloak-appliance-dist-all-1.1.0.Final. Please advise.

Try clearing your cache

> 
> As a side note, I was trying to see if the 1.1.0.Final release correctly
> handled the KEYCLOAK_RESOURCE role added to the Oauth Client for one of my
> realms. Since the usage of this client is trusted, so want to not have to
> grant access to the resources every time for the client. There is nothing in
> the documentation on how to set that up, only in the Login Algorithm page on
> the github wiki. Please advise as how to use this feature.

KEYCLOAK_RESOURCE was an internal role that was used a long time ago. It has never been something you should add yourself.

To prevent grant access from being shown you should use an application not oauth client.

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


From bruno at abstractj.org  Thu Jan 29 03:15:40 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 29 Jan 2015 00:15:40 -0800 (PST)
Subject: [keycloak-dev] Keycloak 1.1.0.Final Released
In-Reply-To: <282508176.2775455.1422515486824.JavaMail.zimbra@redhat.com>
References: <282508176.2775455.1422515486824.JavaMail.zimbra@redhat.com>
Message-ID: <1422519340315.517d3daf@Nodemailer>

Congratulations! Can't wait to try it.



?

abstractj
PGP: 0x84DC9914

On Thu, Jan 29, 2015 at 5:11 AM, Stian Thorgersen <stian at redhat.com>
wrote:

> The Keycloak team is proud to announce the release of Keycloak 1.1.0.Final. Highlights in this release includes:
> * SAML 2.0
> * Clustering
> * Jetty, Tomcat and Fuse adapters
> * HTTP Security Proxy
> * Automatic migration of db schema
> We?re already started working on features for the next release. Some exiting features coming soon includes:
> * Identity brokering
> * Custom user profiles
> * Kerberos
> * OpenID Connect interop
> _______________________________________________
> 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/20150129/db0fb125/attachment-0001.html 

From stian at redhat.com  Thu Jan 29 07:00:02 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 Jan 2015 07:00:02 -0500 (EST)
Subject: [keycloak-dev] Keycloak OpenShift Cartridge updated to 1.1.0.Final
Message-ID: <1029458686.2941961.1422532802250.JavaMail.zimbra@redhat.com>

https://github.com/keycloak/openshift-keycloak-cartridge

From stian at redhat.com  Thu Jan 29 07:29:04 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 Jan 2015 07:29:04 -0500 (EST)
Subject: [keycloak-dev] Keycloak Docker images updated to 1.1.0.Final
Message-ID: <1492777563.2957330.1422534544796.JavaMail.zimbra@redhat.com>

http://www.jboss.org/docker/

From stian at redhat.com  Thu Jan 29 08:02:03 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 Jan 2015 08:02:03 -0500 (EST)
Subject: [keycloak-dev] Follow-up blog posts for 1.1.0.Final release
In-Reply-To: <1201941299.2974716.1422536276274.JavaMail.zimbra@redhat.com>
Message-ID: <41743057.2978329.1422536523469.JavaMail.zimbra@redhat.com>

Over the next few weeks we should do follow-up blog posts on the major new features in 1.1, which would be:

* SAML 2.0
* Clustering (Stian)
* Adapter clustering (Marek)
* New adapters
* HTTP Security Proxy
* Automatic migration of db schema (Stian)

Any volunteers for those without a name already associated with them?

From stian at redhat.com  Thu Jan 29 08:29:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 29 Jan 2015 08:29:31 -0500 (EST)
Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
In-Reply-To: <CAM7bvCSzTupgYmh3uYxkGKe-KXcLc-v_k4cckuEND0YHPws24Q@mail.gmail.com>
References: <CAM7bvCQBnAabSyOPTB=F3-LhhPe1jpvNgmsezAGv4QaaNfTXQw@mail.gmail.com>
	<977292214.7534857.1421048407668.JavaMail.zimbra@redhat.com>
	<CAM7bvCSzTupgYmh3uYxkGKe-KXcLc-v_k4cckuEND0YHPws24Q@mail.gmail.com>
Message-ID: <1091169952.2994208.1422538171584.JavaMail.zimbra@redhat.com>

Finally got a chance to move and look at your video.

I imported your repo to: https://github.com/keycloak/jenkins-keycloak-plugin

I also updated https://wiki.jenkins-ci.org/display/JENKINS/keycloak-plugin to link to the above repo.

Really cool stuff, thanks for contributing this to us :)

----- Original Message -----
> From: "coolmind182006 ." <coolmind182006 at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, January 12, 2015 7:20:24 PM
> Subject: Re: [keycloak-dev] keycloak-oauth-plugin hosting request
> 
> Thanks a bundle, Let me know if I have to do anything..
> 
> 
> 
> On Mon, Jan 12, 2015 at 1:10 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > Awesome, we'd love to pull this in to our GitHub
> >
> > ----- Original Message -----
> > > From: "coolmind182006 ." <coolmind182006 at gmail.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Sunday, 11 January, 2015 12:22:03 PM
> > > Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
> > >
> > >
> > > plugin name : keycloak-oauth
> > > github account : mnadeem
> > > existing repository : https://github.com/mnadeem/jenkins-keycloak-plugin
> > > wiki : https://wiki.jenkins-ci.org/display/JENKINS/keycloak-oauth-plugin
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 

From stian at redhat.com  Fri Jan 30 02:10:58 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jan 2015 02:10:58 -0500 (EST)
Subject: [keycloak-dev] [keycloak-user] Keycloak 1.1.0.Final Released
In-Reply-To: <FAACF693-4B68-4B16-80D5-A2D07BEFCD0B@yahoo.com>
References: <282508176.2775455.1422515486824.JavaMail.zimbra@redhat.com>
	<FAACF693-4B68-4B16-80D5-A2D07BEFCD0B@yahoo.com>
Message-ID: <808566761.3720687.1422601858175.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Raghu Prabhala" <prabhalar at yahoo.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>, "keycloak-user" <keycloak-user at lists.jboss.org>
> Sent: Thursday, January 29, 2015 6:44:11 PM
> Subject: Re: [keycloak-user] Keycloak 1.1.0.Final Released
> 
> Congrats Keycloak team. A great deal of features in this release - really
> like SAML and clustering.
> 
> But what I am really looking for is the next release as we need all the
> features you listed -any tentative dates for the beta version?

We might do a beta soon, but that'll only include identity brokering. The other features will be at least a month away.

> 
> The functionality provided so far seems to be targeted toward users accounts.
> When can we expect support for System accounts (with diff auth mechanisms
> like certificates, Kerberos etc?

Some time this year we aim to have system accounts with certificates, it'll depend on priorities. We don't have any plans to support Kerberos authentication with system accounts, but maybe that makes sense to add as well.

> 
> Thanks,
> Raghu
> 
> Sent from my iPhone
> 
> > On Jan 29, 2015, at 2:11 AM, Stian Thorgersen <stian at redhat.com> wrote:
> > 
> > The Keycloak team is proud to announce the release of Keycloak 1.1.0.Final.
> > Highlights in this release includes:
> > 
> > * SAML 2.0
> > * Clustering
> > * Jetty, Tomcat and Fuse adapters
> > * HTTP Security Proxy
> > * Automatic migration of db schema
> > 
> > We?re already started working on features for the next release. Some
> > exiting features coming soon includes:
> > 
> > * Identity brokering
> > * Custom user profiles
> > * Kerberos
> > * OpenID Connect interop
> > 
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> 


From bgorai at cisco.com  Fri Jan 30 02:22:26 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Fri, 30 Jan 2015 07:22:26 +0000
Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
	Environment
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>

Hi Team,
Please find the details on setup and observation below. Please provide your suggestion on how to overcome this issue. We are using Keycloak 1.0.4.Final (Adapter & Server).


Setup:

1.       We have brought up Jboss cluster ( Using mod_cluster, httpd )  with 2  nodes in domain mode and enabled session replication between these nodes.

2.       Our Recourse server is deployed  in this clustered environment with distributable and Sticky session Off.


Behavior observed :
During the Authorization/Authentication process ,when Initial call(Resource Access) lands on master and next redirection (post Code To token) falls on slave Adapter is treating it as  a new session and redirecting to login URL again. So we ended up with circular redirection error. After further investigation seems like session replication delay is causing adapter to behave this way. As the redirection call happens very quickly and this results in circular redirection error.



NOTE: Sticky Session  in mod_cluster environment solves the issue but  it does not provide true load balancing. Therefore we are not considering Stick session option.


Thanks
Bappaditya Gorai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150130/319fd655/attachment.html 

From stian at redhat.com  Fri Jan 30 02:27:28 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jan 2015 02:27:28 -0500 (EST)
Subject: [keycloak-dev] Facing Issue with Resource Server in
	Clustered	Environment
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>
Message-ID: <1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>

1.0.4.Final had very limited support for clustering, please upgrade to 1.1.0.Final and refer to chapter 24 and 25 in the documentation (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).

----- Original Message -----
> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 30 January, 2015 8:22:26 AM
> Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered	Environment
> 
> 
> 
> Hi Team,
> 
> Please find the details on setup and observation below. Please provide your
> suggestion on how to overcome this issue. We are using Keycloak 1.0.4.Final
> (Adapter & Server).
> 
> 
> 
> 
> 
> Setup:
> 
> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd ) with 2 nodes
> in domain mode and enabled session replication between these nodes.
> 
> 2. Our Recourse server is deployed in this clustered environment with
> distributable and Sticky session Off.
> 
> 
> 
> Behavior observed :
> 
> During the Authorization/Authentication process ,when Initial call(Resource
> Access) lands on master and next redirection (post Code To token) falls on
> slave Adapter is treating it as a new session and redirecting to login URL
> again. So we ended up with circular redirection error. After further
> investigation seems like session replication delay is causing adapter to
> behave this way. As the redirection call happens very quickly and this
> results in circular redirection error.
> 
> 
> 
> 
> 
> 
> 
> NOTE: Sticky Session in mod_cluster environment solves the issue but it does
> not provide true load balancing. Therefore we are not considering Stick
> session option.
> 
> 
> 
> 
> 
> Thanks
> 
> Bappaditya Gorai
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bgorai at cisco.com  Fri Jan 30 02:38:49 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Fri, 30 Jan 2015 07:38:49 +0000
Subject: [keycloak-dev] Facing Issue with Resource Server in
	Clustered	Environment
In-Reply-To: <1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>
	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>

We are not talking about clustering for Keycloak server. The setup is for Resource Server (Keycloak Adapter)  in clustered environment.

Thanks
Bappaditya Gorai

-----Original Message-----
From: Stian Thorgersen [mailto:stian at redhat.com] 
Sent: Friday, January 30, 2015 12:57 PM
To: Bappaditya Gorai (bgorai)
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment

1.0.4.Final had very limited support for clustering, please upgrade to 1.1.0.Final and refer to chapter 24 and 25 in the documentation (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).

----- Original Message -----
> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 30 January, 2015 8:22:26 AM
> Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered	Environment
> 
> 
> 
> Hi Team,
> 
> Please find the details on setup and observation below. Please provide 
> your suggestion on how to overcome this issue. We are using Keycloak 
> 1.0.4.Final (Adapter & Server).
> 
> 
> 
> 
> 
> Setup:
> 
> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd ) with 
> 2 nodes in domain mode and enabled session replication between these nodes.
> 
> 2. Our Recourse server is deployed in this clustered environment with 
> distributable and Sticky session Off.
> 
> 
> 
> Behavior observed :
> 
> During the Authorization/Authentication process ,when Initial 
> call(Resource
> Access) lands on master and next redirection (post Code To token) 
> falls on slave Adapter is treating it as a new session and redirecting 
> to login URL again. So we ended up with circular redirection error. 
> After further investigation seems like session replication delay is 
> causing adapter to behave this way. As the redirection call happens 
> very quickly and this results in circular redirection error.
> 
> 
> 
> 
> 
> 
> 
> NOTE: Sticky Session in mod_cluster environment solves the issue but 
> it does not provide true load balancing. Therefore we are not 
> considering Stick session option.
> 
> 
> 
> 
> 
> Thanks
> 
> Bappaditya Gorai
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Jan 30 02:45:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jan 2015 02:45:54 -0500 (EST)
Subject: [keycloak-dev] Direct links to pages
In-Reply-To: <54C5F0BE.9090002@gmail.com>
References: <54BC4C53.2050300@gmail.com> <54C5F0BE.9090002@gmail.com>
Message-ID: <1991813091.3735627.1422603954680.JavaMail.zimbra@redhat.com>

The URL recently changed, so please upgrade to 1.1.0.Final for these instructions.

Login:

  /auth/realms/example/protocol/openid-connect/login?client_id=<CLIENT ID>&redirect_uri=<REDIRECT URI>&state=<STATE>&response_type=code

Registration:

  /auth/realms/example/protocol/openid-connect/registrations?client_id=<CLIENT ID>&redirect_uri=<REDIRECT URI>&state=<STATE>&response_type=code

* state is optional in 1.1.0, but it is highly recommended and that your application verifies it, especially if you're using cookies


----- Original Message -----
> From: "Christian Beikov" <christian.beikov at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 26 January, 2015 8:46:06 AM
> Subject: Re: [keycloak-dev] Direct links to pages
> 
> Can anyone please confirm that there is or is not a possibility to do this?
> 
> Mit freundlichen Gr??en,
> 
> Christian Beikov
> Am 19.01.2015 um 01:14 schrieb Christian Beikov:
> 
> 
> Hello!
> 
> Quick question. Is there a way to directly link to the registration or login
> page from a different page?
> I tried the following but only get "Bad request" when submitting the form.
> 
> Registration:
> /auth/realms/{realm-name}/tokens/registrations?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fprotected&client_id=protected
> Login:
> /auth/realms/{realm-name}/tokens/login?redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fprotected&client_id=protected
> --
> 
> Mit freundlichen Gr??en,
> 
> Christian Beikov
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Jan 30 02:47:52 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jan 2015 02:47:52 -0500 (EST)
Subject: [keycloak-dev] Facing Issue with Resource Server in
	Clustered	Environment
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>
	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>
Message-ID: <1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 30 January, 2015 8:38:49 AM
> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in Clustered	Environment
> 
> We are not talking about clustering for Keycloak server. The setup is for
> Resource Server (Keycloak Adapter)  in clustered environment.

Same answer

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

From bgorai at cisco.com  Fri Jan 30 05:26:44 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Fri, 30 Jan 2015 10:26:44 +0000
Subject: [keycloak-dev] Facing Issue with Resource Server in
	Clustered	Environment
In-Reply-To: <1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>
	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>
	<1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>

Thanks for clarifying.  So, I think adapter has become stateless in 1.1.0.Final. Is my understanding correct?


-----Original Message-----
From: Stian Thorgersen [mailto:stian at redhat.com] 
Sent: Friday, January 30, 2015 1:18 PM
To: Bappaditya Gorai (bgorai)
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment



----- Original Message -----
> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 30 January, 2015 8:38:49 AM
> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in Clustered	Environment
> 
> We are not talking about clustering for Keycloak server. The setup is 
> for Resource Server (Keycloak Adapter)  in clustered environment.

Same answer

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


From stian at redhat.com  Fri Jan 30 08:25:24 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jan 2015 08:25:24 -0500 (EST)
Subject: [keycloak-dev] Rest password can cause cookie not found
In-Reply-To: <9a852bab-0b46-4aee-af02-4739d601c0eb@me.com>
References: <9a852bab-0b46-4aee-af02-4739d601c0eb@me.com>
Message-ID: <1063921510.3966604.1422624324472.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 27 January, 2015 4:05:14 PM
> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> 
> 
> 
> Am 27. Januar 2015 um 10:49 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> 
> 
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, January 27, 2015 10:33:09 AM
> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> Am 26. Januar 2015 um 20:49 schrieb Bill Burke <bburke at redhat.com>:
> >
> >
> > On 1/26/2015 1:31 PM, Michael Gerber wrote:
> >>> Am 26.01.2015 um 18:36 schrieb Bill Burke <bburke at redhat.com
> >>>
> >>> <mailto:bburke at redhat.com>>:
> >>> On 1/26/2015 12:12 PM, Michael Gerber wrote:
> >>>>> Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke at redhat.com
> >>>>>
> >>>>> <mailto:bburke at redhat.com>>:
> >>>>>> On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> <mailto:keycloak-dev at lists.jboss.org>
> >>>>>>> Sent: Monday, January 26, 2015 2:27:30 PM
> >>>>>>> Subject: Re: [keycloak-dev] Rest password can cause cookie not found
> >>>>>>> Wouldn't this work?
> >>>>>>> 1) store "state" of state cookie in user session.
> >>>>>>> 2) embed user session and state of state cookie in URL
> >>>>>>> Of course this screws up your "shorter URL" crusade.
> >>>>>> I'm not following - the problem isn't remembering the state
> >>>>>> variable in Keycloak, that's already sorted as we already store all
> >>>>>> the query params passed by the client in the client session (state,
> >>>>>> redirect_uri, etc). The problem is storing it on the adapter side.
> >>>>> I think I get it...
> >>>>> 1. Send email
> >>>>> 2. Close browser
> >>>>> 3. Open browser
> >>>>> 4. Click email link
> >>>>> 5. Reset password
> >>>>> 6. Redirect back to app
> >>>>> 7. App barfs because of state cookie
> >>>>> Persistent state cookie sounds like cleanest and simplest solution. I
> >>>>> just worry we'll introduce different bugs, or if we're opening up some
> >>>>> kind of security hole. Maybe I'm just paranoid.
> >>>> That doesn't work if the user uses two different browsers. This is
> >>>> the case in a lot of companies (at least in Switzerland :)) where the
> >>>> users are forced to use ie (default) but rather work with firefox.
> >>> Unless we extend the protocol, or don?t redirect from the email, I
> >>> don?t see a fix.
> >> If the password reset process would redirect without the code and state
> >> param, than the adapter would redirect back to the keycloak, and
> >> keycloak can authenticate the user with its identity cookie?
> >> But I don?t know if that is ok with the protocol.
> >
> > So maybe have a session cookie that is set by the auth server. If that
> > cookie is set when clicking the email url, redirect with code, if not,
> > redirect without it.
> >
> That sounds good, what do the other think about this fallback option?
> I can update the JIRA issue if anybody is happy with th?at solution.
> 
> I'm happy with the idea of setting a session cookie so we can detect if a
> user is using the same browser to complete the flow. However, I don't think
> we should redirect back to the application.
> 
> In this case the user most likely wants to use a different browser for the
> application. For example a user uses Firefox to open the application, click
> on recover password, but then due to company policies IE is registered as
> the default OS browser so links in emails are opened in IE instead. In this
> case the user wants to close IE after resetting the password and go back to
> Firefox to use the application.
> 
> In the case the user is completing the password reset flow in a different
> browser it would be better to update the password, make sure no identity
> cookie or user session is created in the new browser, then just display a
> message "Your password has been updated".
> Why do you want to make sure that no identity cookie is generated?
> Wouldn't it be nice to generate the cookie and display a message to the user
> with a link to the desired redirect uri?
> So, the user can still redirect to the uri without a login?

In the above example the user wanted to login with Firefox, not IE, so why create a SSO session in IE.

You can't redirect back to the application without a code or error, as it's an oauth callback url. If the application has a base url registered we can add a back to application link, but in this case I assume the user is going to want to close IE and go back to Firefox.

> 
> I read that you want to release 1.1.0 Final in the next view days. So I guess
> this bug/feature will be implemented in 1.2.0?
> 
> 
> >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com


From stian at redhat.com  Fri Jan 30 08:25:40 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jan 2015 08:25:40 -0500 (EST)
Subject: [keycloak-dev] Looking for a workaround...
In-Reply-To: <ef0cd52d-966b-45c8-bb13-cf99cc9c5267@me.com>
References: <ef0cd52d-966b-45c8-bb13-cf99cc9c5267@me.com>
Message-ID: <742926378.3966720.1422624340264.JavaMail.zimbra@redhat.com>

What groups would you propose?

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

From stian at redhat.com  Fri Jan 30 09:01:12 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 30 Jan 2015 09:01:12 -0500 (EST)
Subject: [keycloak-dev] [keycloak-user] Keycloak 1.1.0.Final Released
In-Reply-To: <974226441.1786830.1422625454868.JavaMail.yahoo@mail.yahoo.com>
References: <808566761.3720687.1422601858175.JavaMail.zimbra@redhat.com>
	<974226441.1786830.1422625454868.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <1778785947.4002515.1422626472860.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Raghu Prabhala" <prabhalar at yahoo.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>, "keycloak-user" <keycloak-user at lists.jboss.org>
> Sent: Friday, 30 January, 2015 2:44:14 PM
> Subject: Re: [keycloak-user] Keycloak 1.1.0.Final Released
> 
> Great. Looking forward?to the?1.2 Beta version.
> Regarding the system account support, from my perspective, it is very
> important because?we?have thousands of?applications that interact with each
> other using system accounts (authentication with?Kerberos with keytabs) and
> till we have that functionality, we?will?not be able to consider?Keycloak as
> a SSO solution even though it?is coming?out to be a good product. The sooner
> we have it, the better. Hopefully, even other users will pitch in?to request
> that functionality so that you can bump it up in your priority list.
> Thanks once again.Raghu

For your use-case would it have to be Kerberos? Only options we've been considering are certificates and jwt/jws.

> ?      From: Stian Thorgersen <stian at redhat.com>
>  To: Raghu Prabhala <prabhalar at yahoo.com>
> Cc: keycloak dev <keycloak-dev at lists.jboss.org>; keycloak-user
> <keycloak-user at lists.jboss.org>
>  Sent: Friday, January 30, 2015 2:10 AM
>  Subject: Re: [keycloak-user] Keycloak 1.1.0.Final Released
>    
> 
> 
> ----- Original Message -----
> > From: "Raghu Prabhala" <prabhalar at yahoo.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>, "keycloak-user"
> > <keycloak-user at lists.jboss.org>
> > Sent: Thursday, January 29, 2015 6:44:11 PM
> > Subject: Re: [keycloak-user] Keycloak 1.1.0.Final Released
> > 
> > Congrats Keycloak team. A great deal of features in this release - really
> > like SAML and clustering.
> > 
> > But what I am really looking for is the next release as we need all the
> > features you listed -any tentative dates for the beta version?
> 
> We might do a beta soon, but that'll only include identity brokering. The
> other features will be at least a month away.
> 
> > 
> > The functionality provided so far seems to be targeted toward users
> > accounts.
> > When can we expect support for System accounts (with diff auth mechanisms
> > like certificates, Kerberos etc?
> 
> Some time this year we aim to have system accounts with certificates, it'll
> depend on priorities. We don't have any plans to support Kerberos
> authentication with system accounts, but maybe that makes sense to add as
> well.
> 
> 
> 
> > 
> > Thanks,
> > Raghu
> > 
> > Sent from my iPhone
> > 
> > > On Jan 29, 2015, at 2:11 AM, Stian Thorgersen <stian at redhat.com> wrote:
> > > 
> > > The Keycloak team is proud to announce the release of Keycloak
> > > 1.1.0.Final.
> > > Highlights in this release includes:
> > > 
> > > * SAML 2.0
> > > * Clustering
> > > * Jetty, Tomcat and Fuse adapters
> > > * HTTP Security Proxy
> > > * Automatic migration of db schema
> > > 
> > > We?re already started working on features for the next release. Some
> > > exiting features coming soon includes:
> > > 
> > > * Identity brokering
> > > * Custom user profiles
> > > * Kerberos
> > > * OpenID Connect interop
> > > 
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > 
> 
> 


From coolmind182006 at gmail.com  Fri Jan 30 12:29:31 2015
From: coolmind182006 at gmail.com (coolmind182006 .)
Date: Fri, 30 Jan 2015 22:59:31 +0530
Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
In-Reply-To: <1091169952.2994208.1422538171584.JavaMail.zimbra@redhat.com>
References: <CAM7bvCQBnAabSyOPTB=F3-LhhPe1jpvNgmsezAGv4QaaNfTXQw@mail.gmail.com>
	<977292214.7534857.1421048407668.JavaMail.zimbra@redhat.com>
	<CAM7bvCSzTupgYmh3uYxkGKe-KXcLc-v_k4cckuEND0YHPws24Q@mail.gmail.com>
	<1091169952.2994208.1422538171584.JavaMail.zimbra@redhat.com>
Message-ID: <CAM7bvCRhJjC8jXdQpsk_nmLpJkHwHOikE9g_D6G5LXheLsQt2Q@mail.gmail.com>

Thanks Stian,

I am planning to provide Authorization for Jenkins, which is not yet
implemented, After I am done with that, How that would be merged with
keycloak repo ?, since I don't have write access to keycloak some manual
work would be required to merge the code back to keycloak repo from my
personal repo

Further I written a blog on deploying keycloak on Tomcat
<https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomcat/>and
Tomee
<https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomee/>

And Finally Sonarqube is also integrated with Keycloak
<https://reachmnadeem.wordpress.com/2015/01/22/integrating-keycloak-with-sonarqube/>

I will provide authorization soon for sonarqube as well





On Thu, Jan 29, 2015 at 6:59 PM, Stian Thorgersen <stian at redhat.com> wrote:

> Finally got a chance to move and look at your video.
>
> I imported your repo to:
> https://github.com/keycloak/jenkins-keycloak-plugin
>
> I also updated https://wiki.jenkins-ci.org/display/JENKINS/keycloak-plugin
> to link to the above repo.
>
> Really cool stuff, thanks for contributing this to us :)
>
> ----- Original Message -----
> > From: "coolmind182006 ." <coolmind182006 at gmail.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Monday, January 12, 2015 7:20:24 PM
> > Subject: Re: [keycloak-dev] keycloak-oauth-plugin hosting request
> >
> > Thanks a bundle, Let me know if I have to do anything..
> >
> >
> >
> > On Mon, Jan 12, 2015 at 1:10 PM, Stian Thorgersen <stian at redhat.com>
> wrote:
> >
> > > Awesome, we'd love to pull this in to our GitHub
> > >
> > > ----- Original Message -----
> > > > From: "coolmind182006 ." <coolmind182006 at gmail.com>
> > > > To: keycloak-dev at lists.jboss.org
> > > > Sent: Sunday, 11 January, 2015 12:22:03 PM
> > > > Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
> > > >
> > > >
> > > > plugin name : keycloak-oauth
> > > > github account : mnadeem
> > > > existing repository :
> https://github.com/mnadeem/jenkins-keycloak-plugin
> > > > wiki :
> https://wiki.jenkins-ci.org/display/JENKINS/keycloak-oauth-plugin
> > > >
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150130/c02c0e87/attachment.html