[keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem

Stan Silvert ssilvert at redhat.com
Mon Nov 3 08:22:42 EST 2014 

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.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at 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 at redhat.com>
>>>> To: "Stan Silvert" <ssilvert at redhat.com>
>>>> Cc: keycloak-dev at 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 at redhat.com>
>>>>> To: "Stan Silvert" <ssilvert at redhat.com>
>>>>> Cc: keycloak-dev at 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 at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: keycloak-dev at 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 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
>>>>
>>

More information about the keycloak-dev mailing list