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 On Thu, Oct 4, 2018 at 4:59 PM Suresh Marru <[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 > [2] - > https://github.com/apache/airavata/tree/develop/airavata-services/profile-service > [3] - > https://github.com/apache/airavata/tree/develop/airavata-services/services-security > [4] - > https://github.com/apache/airavata/tree/develop/modules/credential-store > [5] - > https://github.com/apache/airavata/tree/master/modules/sharing-registry > [6] - http://doi.ieeecomputersociety.org/10.1109/eScience.2016.7870911 > [7] - https://doi.org/10.6084/m9.figshare.5483557.v1 > [8] - https://doi.org/10.1145/3093338.3093359 > [9] - https://doi.org/10.1109/CCGrid.2014.95 >
