<div dir="ltr">Dear all,<div><br></div><div>The short story that we want to move from <a href="http://login.launchpad.net">login.launchpad.net</a> to an infra hosted solution at <a href="http://openstackid.org">openstackid.org</a>, so the plan is that infra team will operate the service in the future. The advantage of this service over the existing one, that it is directly connected with <a href="http://openstack.org">openstack.org</a> profile database, so this can be the basic source of profile and auth data for all OpenStack services.</div><div><br></div><div>The service behind <a href="http://openstackid.org">openstackid.org</a> had been written by a third party, and it is based on a PHP/Laravel framework. The source code is accessible at <a href="https://github.com/openstack-infra/openstackid">https://github.com/openstack-infra/openstackid</a>, and all of the deployment scripts available at openstack-infra/system-config repo.</div><div><br></div><div>As this service will handle authentication and membership data, I want to ask whether any of you as the member of openstack security team would like to suggest some extra hardening or security related advice to lower the possibly security risks of operating such a service.</div><div><br></div><div>We have several options in our mind:</div><div>a, put a simple cloudflare service in front of <a href="http://openstackid.org">openstackid.org</a> to filter out well-known patterns as a hosted solution</div><div>b, put a mod_security hosted by Us and in front of <a href="http://openstackid.org">openstackid.org</a></div><div>c, do a code-audit on the openstackid source code</div><div>d, trust-in the code and open up the service without any other security consideration</div><div><br></div><div>I appreciate all your feedbacks in this topic.</div><div><br></div><div>Brgds,</div><div>  Marton Kiss</div></div>