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

Stan Silvert ssilvert at redhat.com
Tue Nov 4 07:26:16 EST 2014 

On 11/4/2014 6:08 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: Tuesday, 4 November, 2014 11:54:09 AM
>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
>>
>> 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.
> Yes, provider developers.
>
> We have made it harder. They have to explode the war and change the setting in standalone.xml. We've also moved the auth-server.war to a harder to find location.
Fair enough.  It's slightly harder.  Do you think it will still be 
harder once we have script support?
>
>>> * 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.
> That's a real shame, it would have been so much nicer if users could just drop a jar into a directory.
Yea, I wasted a lot of time going down that road just to find out it was 
a dead end.
>
>> 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.
> I thought you just said you can't use a deployment scanner?
I think I wasn't clear.  You can't use a deployment scanner in domain 
mode.  You can't use a deployment scanner for overlays no matter what.
>
>>> ----- 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