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

Mon Nov 3 08:08:26 EST 2014

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?

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