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]> 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]> > 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]> 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 >> >> >> 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 >>> >> >> >> >> >
