Ok, we'll not include this in Beta1.
I'd like to see a solution to deploying providers that:
* Can be scripted
* Makes life easy for developers
* Can also be done while server is not running (I'm confused to why the overlays has
to be uploaded through a CLI, and can't just be copied to a directory and manually
added to standalone.xml)
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Monday, 3 November, 2014 7:42:13 PM
Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
On 11/3/2014 1:13 PM, Stian Thorgersen wrote:
> I thought you could point to a file on the file-system for the overlay.
>
> In that case if the only options are CLI GUI or adding to the WAR, we
> should have the WAR exploded for now.
I disagree. Using the CLI GUI command is simpler and less error-prone
than manual copying.
Manual copying in domain mode means copying the provider jar to every
instance where it will be deployed. And in the case where you want
multiple Keycloak instances, every instance will get the same providers
and the same keycloak-server.json.
Is it really such a problem that we will go one release without CLI
scripting support? If it is then I'd rather delay the whole merge
until the next release. That's not something I would oppose in any
case. I want everyone to be comfortable with this because it is a
fairly big change.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Monday, 3 November, 2014 6:52:26 PM
>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
>> KC subsystem
>>
>> On 11/3/2014 11:21 AM, Stian Thorgersen wrote:
>>> What about we just add an example snippet of the XML required to add a
>>> provider manually (no cli) to standalone.xml? IMO that'd be good enough
>>> for Beta1.
>> It isn't done using XML. You have to somehow upload the bits to the
>> server's content repository. That can be done via CLI GUI or by
>> manually adding the bits to the WAR before it is deployed.
>>
>> The point here is that even if you can't yet do this in a CLI script,
>> you aren't losing anything over the way it is done today. It is still
>> possible to manually copy the jar into the WAR.
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>>> To: keycloak-dev(a)lists.jboss.org
>>>> Sent: Monday, 3 November, 2014 4:10:39 PM
>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server
into
>>>> KC subsystem
>>>>
>>>> On 11/3/2014 8:22 AM, Stan Silvert wrote:
>>>>> On 11/3/2014 8:08 AM, Stian Thorgersen wrote:
>>>>>> With deployment overlays
>>>>>>
(
https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays) is
>>>>>> it
>>>>>> possible to refer to files in the file-system? Can we use that
to add
>>>>>> a
>>>>>> provider?
>>>>> Yes. The only difference is that the "deployment-overlay"
command is a
>>>>> lot more complicated and error prone. The result is the same though
if
>>>>> you use it correctly. So we could just document that.
>>>>>
>>>>> I guess that's a good solution for now. For
"add-provider" and
>>>>> "update-server-config", I'll document the equivalent
>>>>> "deployment-overlay" command that can be used in a
script.
>>>> I just heard back from Alex and he wants to add the functionality to
CLI
>>>> that I added to CLI GUI. So at the end of the day, the commands will
be
>>>> the same in CLI and CLI GUI.
>>>>
>>>> Instead of documenting equivalent "deployment-overlay"
commands, I'll
>>>> work on that instead.
>>>>
>>>> I don't think that lack of scripting support should delay the
release.
>>>> IMO, if everyone is comfortable with the overall change, we can go
ahead
>>>> and merge. But waiting until next release is OK as well.
>>>>>> ----- Original Message -----
>>>>>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>>>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>>>>> Sent: Monday, 3 November, 2014 1:54:31 PM
>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth
Server
>>>>>>> into
>>>>>>> KC subsystem
>>>>>>>
>>>>>>> Just a documentation task then.
>>>>>>>
>>>>>>> You can still deploy the auth-server.war in exploded format
just like
>>>>>>> we
>>>>>>> do today. I'll add a section in the doc for that.
>>>>>>>
>>>>>>> Or, you can use other means to put files into the unexploded
war. (Do
>>>>>>> it
>>>>>>> by hand or use Maven war overlay).
>>>>>>>
>>>>>>> I welcome other suggestions on updating the docs. We still
need to
>>>>>>> document how to do this the old way because these subsystem
>>>>>>> enhancements
>>>>>>> only apply to WildFly.
>>>>>>>
>>>>>>> I'll ping Alex about getting this into regular CLI so it
is
>>>>>>> scriptable.
>>>>>>> Otherwise, I could write a CLI add-on that allows you to do
this in a
>>>>>>> CLI script.
>>>>>>>
>>>>>>> On 11/3/2014 6:02 AM, Stian Thorgersen wrote:
>>>>>>>> Before we can add this PR we need to make it possible to
add
>>>>>>>> providers
>>>>>>>> and
>>>>>>>> update server config without using the CLI GUI. This may
just be a
>>>>>>>> documentation task, but it has to be possible to script
these tasks
>>>>>>>> as
>>>>>>>> well as perform them without using a GUI.
>>>>>>>>
>>>>>>>> We also need to update the provider examples as they
currently asks
>>>>>>>> the
>>>>>>>> user to copy to WEB-INF/lib.
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Stian Thorgersen"
<stian(a)redhat.com>
>>>>>>>>> To: "Stan Silvert"
<ssilvert(a)redhat.com>
>>>>>>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>>>>>>> Sent: Monday, 3 November, 2014 11:28:33 AM
>>>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795:
Move Auth Server
>>>>>>>>> into
>>>>>>>>> KC subsystem
>>>>>>>>>
>>>>>>>>> Actually, thinking about it we should just drop the
confidential
>>>>>>>>> setting
>>>>>>>>> in
>>>>>>>>> web.xml.
>>>>>>>>>
>>>>>>>>> #1 We have ssl-required on realm - there may be
traffic where we
>>>>>>>>> don't
>>>>>>>>> check,
>>>>>>>>> but we should improve instead of relying on setting
in web.xml
>>>>>>>>> #2 Users shouldn't access Keycloak directly -
users click on links
>>>>>>>>> in
>>>>>>>>> applications they don't navigate to a page on KC
itself, so there's
>>>>>>>>> not
>>>>>>>>> really a need to do the redirect from http
>>>>>>>>> #3 Could be risky - if an application uses a custom
adapter/lib (or
>>>>>>>>> have
>>>>>>>>> the
>>>>>>>>> wrong ssl-required in keycloak.json) and a http
library that
>>>>>>>>> automatically
>>>>>>>>> follows the redirect. This would mean that an
application posts
>>>>>>>>> code
>>>>>>>>> and
>>>>>>>>> client secret to http://.., which returns a 302, the
http library
>>>>>>>>> then
>>>>>>>>> re-posts to https://... Keycloak would think all
requests are done
>>>>>>>>> using
>>>>>>>>> ssl
>>>>>>>>> (as it doesn't see the initial http request,
only the app server
>>>>>>>>> does)
>>>>>>>>> and
>>>>>>>>> the developer could also be unaware of this, the end
result being
>>>>>>>>> that
>>>>>>>>> an
>>>>>>>>> application would post codes and secrets in
clear-text as well as
>>>>>>>>> post
>>>>>>>>> every
>>>>>>>>> request twice.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Stian Thorgersen"
<stian(a)redhat.com>
>>>>>>>>>> To: "Stan Silvert"
<ssilvert(a)redhat.com>
>>>>>>>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>>>>>>>> Sent: Monday, 3 November, 2014 9:19:15 AM
>>>>>>>>>> Subject: Re: [keycloak-dev] Notes on
KEYCLOAK-795: Move Auth
>>>>>>>>>> Server
>>>>>>>>>> into
>>>>>>>>>> KC
>>>>>>>>>> subsystem
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Stan Silvert"
<ssilvert(a)redhat.com>
>>>>>>>>>>> To: "Stian Thorgersen"
<stian(a)redhat.com>
>>>>>>>>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>>>>>>>>> Sent: Friday, 31 October, 2014 7:42:34 PM
>>>>>>>>>>> Subject: Re: [keycloak-dev] Notes on
KEYCLOAK-795: Move Auth
>>>>>>>>>>> Server
>>>>>>>>>>> into
>>>>>>>>>>> KC
>>>>>>>>>>> subsystem
>>>>>>>>>>>
>>>>>>>>>>> On 10/31/2014 4:15 AM, Stian Thorgersen
wrote:
>>>>>>>>>>>> Looks good to me. We should include this
in Beta1.
>>>>>>>>>>>>
>>>>>>>>>>>> A few comments/questions:
>>>>>>>>>>>>
>>>>>>>>>>>> * Can we support enabling confidential
transport-guarantee
>>>>>>>>>>>> (auth-server/WEB-INF/web.xml) without
cracking open the WAR?
>>>>>>>>>>>> This
>>>>>>>>>>>> seems
>>>>>>>>>>>> to
>>>>>>>>>>>> be the last requirement for an exploded
WAR
>>>>>>>>>>> Looking this over, it seems pretty
important! I think I'd like
>>>>>>>>>>> to
>>>>>>>>>>> go
>>>>>>>>>>> ahead and implement this option before we
merge. I should be
>>>>>>>>>>> able
>>>>>>>>>>> to
>>>>>>>>>>> do
>>>>>>>>>>> that and also finish the doc updates by the
middle of next week.
>>>>>>>>>>> Just
>>>>>>>>>>> go ahead and release the Beta if you want.
I can catch the next
>>>>>>>>>>> release
>>>>>>>>>>> train.
>>>>>>>>>>>
>>>>>>>>>>> I plan to implement this as a boolean value
on on the server
>>>>>>>>>>> called
>>>>>>>>>>> "https-required". Is there a
better name for it?
>>>>>>>>>>> <subsystem
xmlns="urn:jboss:domain:keycloak:1.0">
>>>>>>>>>>> <auth-server
name="foo">
>>>>>>>>>>>
<enabled>true</enabled>
>>>>>>>>>>>
<web-context>auth</web-context>
>>>>>>>>>>>
<https-required>true</https-required>
>>>>>>>>>>> </auth-server>
>>>>>>>>>>> </subsystem>
>>>>>>>>>>>
>>>>>>>>>>> Should the default be false? I realize that
the default in the
>>>>>>>>>>> appliance dist is false, but should the
default always be false?
>>>>>>>>>> We already have the option
'ssl-required' on a realm, so that may
>>>>>>>>>> be
>>>>>>>>>> confusing. What about
'redirect-non-ssl'?
>>>>>>>>>>
>>>>>>>>>> It shouldn't be on by default, as that would
require setting up
>>>>>>>>>> ssl
>>>>>>>>>> for
>>>>>>>>>> development as well. We have the
'ssl-required' set to 'external'
>>>>>>>>>> to
>>>>>>>>>> give
>>>>>>>>>> us
>>>>>>>>>> a compromise between usability and security.
>>>>>>>>>>
>>>>>>>>>>> If true, this will be automatically added to
auth-server.war at
>>>>>>>>>>> deploy
>>>>>>>>>>> time:
>>>>>>>>>>>
>>>>>>>>>>> <security-constraint>
>>>>>>>>>>> <web-resource-collection>
>>>>>>>>>>>
<url-pattern>/*</url-pattern>
>>>>>>>>>>> </web-resource-collection>
>>>>>>>>>>> <user-data-constraint>
>>>>>>>>>>>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
>>>>>>>>>>> </user-data-constraint>
>>>>>>>>>>> </security-constraint>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>