<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 6, 2016 at 6:29 PM, David Stanek <span dir="ltr"><<a href="mailto:dstanek@dstanek.com" target="_blank">dstanek@dstanek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span class=""><div dir="ltr">On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic <<a href="mailto:bpavlovic@mirantis.com" target="_blank">bpavlovic@mirantis.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>2) This will reduce scope of Keystone, which means 2 things</div><div>2.1) Smaller code base that has less issues and is simpler for testing</div><div>2.2) Keystone team would be able to concentrate more on fixing perf/scalability issues of authorization, which is crucial at the moment for large clouds.</div></div></blockquote><div><br></div></span><div>I'm not sure that this is entirely true. If we truly just split up the project, meaning we don't remove functionality, then we'd have the same number of bugs and work. It would just be split across two projects.</div><div><br></div><div>I think the current momentum to get out of the authn business is still our best bet. As Steve mentioned this is ongoing work.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- David</div></font></span></div></div>
<br></blockquote><div><br></div><div>What everyone else said... but add in the need then to either pass the AuthN over to the Assignment/AuthZ api or bake it in (via apache module?) and we are basically where we are now.</div><div><br></div><div>Steve alluded to splitting out the authentication bit (but not to a new service), the idea there is to make it so AuthN is not part of the CRUD interface of the server. All being said, AuthN and AuthZ are going to be hard to split into two separate services and with exception of the unfounded "scope" benefit, we already can handle most of what you've proposed with zero changes to Keystone.</div><div><br></div><div>Cheers,</div><div>--Morgan</div></div><br></div></div>