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

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.

> ----- Original Message ----- >> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>> To: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>> To: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>>>> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>>> Cc: keycloak-dev(a)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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev