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.
----- 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
>>>
>