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

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