[keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
Stan Silvert
ssilvert at redhat.com
Tue Nov 4 05:54:09 EST 2014
On 11/4/2014 2:51 AM, Stian Thorgersen wrote:
> 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
I assume you mean provider developers? We haven't taken anything away
from them, so it's at least no harder. They will be able to either use
exploded mode or run a script.
> * 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)
That's a long, long story. Originally, I wanted to have a directory
for overlays and make it work sort of like a deployment scanner.
Unfortunately, I found that is impossible for overlays without some
substantial changes to WildFly. Overlays can't use a deployment scanner
of any kind.
Deployments and overlays are never manually added to standalone.xml.
That's just the way WildFly works. You either upload with a tool like
CLI or web console, or (if standalone) you let a deployment scanner find
it. For domain mode, only uploading is allowed.
>
> ----- 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 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 at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at 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 at redhat.com>
>>>>>> To: keycloak-dev at 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 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
>>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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