Hi Thejaka, Sorry I was not clear, PSA stands for Python Social Auth https://github.com/python-social-auth/social-core
And I agree, as long as we avoid generic approaches and build the backend Keycloak/Custos-specific, we'll be on a preferred track where independent from changes to IdPs. Best, _____________ *Vahid Jalili, *Ph.D. Computational Biologist Computational Biology Institute Oregon Health and Science University 2730 SW Moody Ave, KCRB #3103.20, OHSU-RLSB Dock 61, Portland, OR, USA 97201 Skype ID: v.jalili On Sat, Mar 2, 2019 at 9:14 AM Thejaka Amila J Kanewala < [email protected]> wrote: > Hello Vahid, > > Thank you for the clarification. The latter approach makes more sense. > BTW, what is PSA? (sorry for asking a lot of question). > > Best Regards > Thejaka > > On Thu, Feb 28, 2019 at 7:14 PM Vahid Jalili <[email protected]> > wrote: > > > Hi Marcus, > > > > Yes, I agree; a PSA-based integration would be simpler for now, but can > > limit our maneuverability overtime. Note that, in a PSA-based approach a > > backend should adhere with the requirements of base protocol. So, for > > instance, since OIDC-protocol does not have means of AWS access and > secret > > key exchange, and if had implemented this backend in PSA, then we would > not > > be able to offer this service. > > > > I agree with your current approach, we only need to address some points > > that prevent Galaxy from being decoupled from IdP (e.g., the well knowns > as > > you mentioned). > > > > We did not discuss the naming, "oidc" vs "keycloak" or "custos". Shall we > > postpone it to Tuesday or prefer to follow in this thread? > > > > Best, > > _____________ > > *Vahid Jalili, *Ph.D. > > Computational Biologist > > Computational Biology Institute > > Oregon Health and Science University > > 2730 SW Moody Ave, KCRB #3103.20, > > OHSU-RLSB Dock 61, > > Portland, OR, USA 97201 > > Skype ID: v.jalili > > > > > > > > > > On Thu, Feb 28, 2019 at 1:27 PM Christie, Marcus Aaron <[email protected]> > > wrote: > > > > > Hi Vahid, > > > > > > I think you've hit on a really good point that makes me lean toward the > > > current custos integration approach instead of PSA so we have the > > > flexibility to handle this use case. > > > > > > Marlon was right to suggest we sleep on it. I'm inclined to not go the > > PSA > > > route. We can always revisit in the future if we find that Custos > > > authentication can fit in the PSA abstraction; it may be a good way to > > > simplify Custos integration for Python based gateways. > > > > > > To address the Galaxy concern about well known urls, I was thinking > that > > > we can create a Python Custos client library that would only define > these > > > urls for now but that would over time become a real client to the > Custos > > > API. > > > > > > Thanks, > > > > > > Marcus > > > > > > > On Feb 26, 2019, at 4:26 PM, Vahid Jalili <[email protected]> > > > wrote: > > > > > > > > Hi All, > > > > > > > > One of the points may worth consideration before this integration is > > that > > > > how it works with "hint endpoints": telling Keycloak which backend of > > > > CILogon to be used hence to bypass keycloak/CILogon page and visit > > > directly > > > > to the IdP's login page? > > > > > > > > Best, > > > > _____________ > > > > *Vahid Jalili, *Ph.D. > > > > Postdoctoral Scholar > > > > Computational Biology Institute > > > > Oregon Health and Science University > > > > 2730 SW Moody Ave, KCRB #3103.20, > > > > OHSU-RLSB Dock 61, > > > > Portland, OR, USA 97201 > > > > Skype ID: v.jalili > > > > > > > > > > > -- > Best Regards, > Thejaka Amila Kanewala, PhD > https://github.com/thejkane/agm >
