Sounds good, I will initiate the repo request now. Suresh
> On Oct 5, 2018, at 11:42 AM, Thejaka Amila J Kanewala > <[email protected]> wrote: > > Hi Suresh, > > Can we request for the repo now ? > Then we can start setting up the infrastructure for the project and we need > to do this irrespective of our approach. > > Thanks > Thejaka > > On Thu, Oct 4, 2018 at 10:14 PM Suresh Marru <[email protected] > <mailto:[email protected]>> wrote: > 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 <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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> >> >> >> >
