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