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

Stian Thorgersen stian at redhat.com
Tue Nov 4 02:51:58 EST 2014


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