Hi Amila, Supun, Before I started this thread I was thinking back and forth on whether to pull out the code and make it general purpose or go with the approach you are proposing. Let me contradict myself and pile on your suggestions. Even though it will take longer (relative to my original suggestion), it will be cleaner and will give us an opportunity to re-think or revisit some of the original assumptions. I will wait for others to weigh in as well and will proceed with new repo.
Cheers, Suresh > On Oct 4, 2018, at 8:55 PM, Supun Nakandala <supun.nakand...@gmail.com> wrote: > > Hi Suresh, > > I too agree with Amila's suggestion. The security components inside Airavata > do have a broader applicability. But the current implementations of these > components assume certain conditions which are specific to the Airavata > system. These include simple things like terminology to more critical ones > such as assumptions on the security model itself (e.g. All the authentication > and authorization will be handled by the API server at the first intercept of > a request). > > I think this will be a good opportunity to evaluate the existing components > from a security model point of view and also to assess their implementation > quality and the vulnerabilities of other components that they use. > > +1 for new repo > Best > Supun > > On Thu, Oct 4, 2018 at 5:24 PM Thejaka Amila J Kanewala > <thejaka.am...@gmail.com <mailto:thejaka.am...@gmail.com>> wrote: > Hi Suresh, > > I like moving the security functionality to new repo but I am not sure > whether I like to move the code as it is to another repository. > The basic approach I am thinking is as follows: > > 1. Identify the generic security feature provided by each of these components > 2. Come up with a generic implementation of the security component -- this > new implementation will reside in a repository different from Airavata > 3. Refactor airavata security component to use the new library > > Name suggestions: Custos, Cuztos > > Also, I see that this new project will utilize two disciplines: Engineering & > Research. Engineering is to generalize security features and bundle them into > a single product. We should try to use existing stable and active open source > security projects. In functionality wise this should include security > features already utilized by organizations (OAuth, OpenId, SAML etc.). > Research component should focus on finding new problems related to security > (authentication, authorization, confidentiality, integrity, auditing, > isolation, sharing, privacy etc.) and science gateways and solutions to them. > > +1 for creating a new repo. > > -- > Best Regards, > Thejaka Amila Kanewala, PhD > https://github.com/thejkane/agm <https://github.com/thejkane/agm> > > On Thu, Oct 4, 2018 at 4:59 PM Suresh Marru <sma...@apache.org > <mailto:sma...@apache.org>> wrote: > Hi All, > > tl;dr. Bundle all airavata security components into a unified security > system, bootstrap a new apache project and grow a community around it > > Airavata code base has been organically growing and it might help to fork off > some major capabilities into sub-projects. Security components are a good > example of such sub-system. It might help to nurture a separate community > around these. I will hold-off on long-term directions, but would like to > start a discussion to discuss the merits of such effort. With full > disclosure, we are motivated by a recent funding award [1] from National > Science Foundation to Indiana University, University of Illinois and Johns > Hopkins University. > > Any objections to move components [2], [3], [4], [5] into a separate repo and > call it airavata-security? (name suggestions welcome). Papers [6], [7], [8], > [9] describe these comments at least at a conceptual level. If there are no > objections, I would like to request INFRA to create a new repo, move these > components into it and experiment with Airavata to depend upon it. Once we > validate the stand alone security repository can work well for Airavata, we > can reach out to potential external usage. If there is a quorum, we can > potentially propose this to Incubator to seed a community and let it grow on > its own. > > Comments, questions, gripe's? > > Cheers, > Suresh > > [1] - https://www.nsf.gov/awardsearch/showAward?AWD_ID=1840003 > <https://www.nsf.gov/awardsearch/showAward?AWD_ID=1840003> > [2] - > https://github.com/apache/airavata/tree/develop/airavata-services/profile-service > > <https://github.com/apache/airavata/tree/develop/airavata-services/profile-service> > [3] - > https://github.com/apache/airavata/tree/develop/airavata-services/services-security > > <https://github.com/apache/airavata/tree/develop/airavata-services/services-security> > [4] - > https://github.com/apache/airavata/tree/develop/modules/credential-store > <https://github.com/apache/airavata/tree/develop/modules/credential-store> > [5] - https://github.com/apache/airavata/tree/master/modules/sharing-registry > <https://github.com/apache/airavata/tree/master/modules/sharing-registry> > [6] - http://doi.ieeecomputersociety.org/10.1109/eScience.2016.7870911 > <http://doi.ieeecomputersociety.org/10.1109/eScience.2016.7870911> > [7] - https://doi.org/10.6084/m9.figshare.5483557.v1 > <https://doi.org/10.6084/m9.figshare.5483557.v1> > [8] - https://doi.org/10.1145/3093338.3093359 > <https://doi.org/10.1145/3093338.3093359> > [9] - https://doi.org/10.1109/CCGrid.2014.95 > <https://doi.org/10.1109/CCGrid.2014.95> > > >
