[keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
Stian Thorgersen
stian at redhat.com
Mon Nov 3 11:21:18 EST 2014
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.
----- 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