You are viewing a plain text version of this content. The canonical link for it is here.
Posted to custos@airavata.apache.org by Vahid Jalili <ja...@gmail.com> on 2019/03/01 00:13:32 UTC
Re: custos integration with Galaxy via PSA
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 <ma...@iu.edu>
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 <ja...@gmail.com>
> 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
>
>
Re: custos integration with Galaxy via PSA
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
> On Mar 12, 2019, at 1:20 PM, Vahid Jalili <ja...@gmail.com> wrote:
>
> We are going to be able to login with an IdP via multiple implementations.
> For instance, login with Google via PSA or Custos.
>
> https://github.com/galaxyproject/galaxy/blob/dev/config/oidc_backends_config.xml.sample <https://github.com/galaxyproject/galaxy/blob/dev/config/oidc_backends_config.xml.sample>
>
> In case of custos, enabling a backend might be as easy as just whitelisting
> it, because you provide Galaxy with credentials to access Custos only
> (i.e., only custos client ID and secret). That is because Custos is a
> broker in the middle. However, in case of PSA, you would need to provide
> credentials for each backend. So, you may *not* be able to use PSA as:
>
> <provider name="PSA">
> <client_id> ... </client_id>
> <client_secret> ... </client_secret>
> <included_idp>
> <idp>Google</idp>
> <idp>Globus</idp>
> </included_idp>
> </provider>
>
> because each idp has its own credentials. Therefore, we may need to define
> a configuration consistent between implementations (e.g., PSA and Custos
> for now).
We discussed this on the call but just to document the conclusion, we decided to go ahead with removing the implementation attribute. The implementation to use (PSA or Custos) will be based on the name of the provider, as is currently the case.
How to whitelist/blacklist idps for Custos we left as something to be figured out later.
Re: custos integration with Galaxy via PSA
Posted by Vahid Jalili <ja...@gmail.com>.
Hi Marcus,
We are going to be able to login with an IdP via multiple implementations.
For instance, login with Google via PSA or Custos.
https://github.com/galaxyproject/galaxy/blob/dev/config/oidc_backends_config.xml.sample
In case of custos, enabling a backend might be as easy as just whitelisting
it, because you provide Galaxy with credentials to access Custos only
(i.e., only custos client ID and secret). That is because Custos is a
broker in the middle. However, in case of PSA, you would need to provide
credentials for each backend. So, you may *not* be able to use PSA as:
<provider name="PSA">
<client_id> ... </client_id>
<client_secret> ... </client_secret>
<included_idp>
<idp>Google</idp>
<idp>Globus</idp>
</included_idp>
</provider>
because each idp has its own credentials. Therefore, we may need to define
a configuration consistent between implementations (e.g., PSA and Custos
for now).
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 Mon, Mar 11, 2019 at 6:48 AM Christie, Marcus Aaron <ma...@iu.edu>
wrote:
> Hi Vahid,
>
> On Mar 7, 2019, at 12:30 PM, Vahid Jalili <ja...@gmail.com> wrote:
>
> Regarding the configuration: I think we still want to be able to login to
> Google via either/both Custos and PSA, is that still the case? if so, I
> think your previous configuration would make more sense where you had
> "<provider name="Google" implementation="Custos">" specifying the IdP name
> and the implementation that interfaces that IdP.
>
>
> Yes, you can log into Google via Custos through CILogon. But I don't think
> we've decided how to configure that. I was thinking that from Galaxy's
> perspective the "provider" is Custos and the user select's Google in the
> user interface. The Custos integration in Galaxy will pass this identity
> provider selection through to CILogon which will in turn redirect to
> Google, etc.
>
> A Galaxy Admin might want to only permit the Google identity provider with
> Custos and for that I think we could have some kind of whitelist/blacklist
> configuration. For example:
>
> <provider name="Custos">
> <client_id>...</client_id>
> <client_secret>...</client_secret>
> <redirect_uri>
> http://localhost:8000/authnz/custos/callback</redirect_uri>
> <realm>...</realm>
> <included-idps>
> <included-idp> ... Google's idp identifier ... </included-idp>
> </included-idps>
> </provider>
>
> Thanks,
>
> Marcus
>
Re: custos integration with Galaxy via PSA
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
Hi Vahid,
> On Mar 7, 2019, at 12:30 PM, Vahid Jalili <ja...@gmail.com> wrote:
>
> Regarding the configuration: I think we still want to be able to login to
> Google via either/both Custos and PSA, is that still the case? if so, I
> think your previous configuration would make more sense where you had
> "<provider name="Google" implementation="Custos">" specifying the IdP name
> and the implementation that interfaces that IdP.
Yes, you can log into Google via Custos through CILogon. But I don't think we've decided how to configure that. I was thinking that from Galaxy's perspective the "provider" is Custos and the user select's Google in the user interface. The Custos integration in Galaxy will pass this identity provider selection through to CILogon which will in turn redirect to Google, etc.
A Galaxy Admin might want to only permit the Google identity provider with Custos and for that I think we could have some kind of whitelist/blacklist configuration. For example:
<provider name="Custos">
<client_id>...</client_id>
<client_secret>...</client_secret>
<redirect_uri>http://localhost:8000/authnz/custos/callback</redirect_uri>
<realm>...</realm>
<included-idps>
<included-idp> ... Google's idp identifier ... </included-idp>
</included-idps>
</provider>
Thanks,
Marcus
Re: custos integration with Galaxy via PSA
Posted by Vahid Jalili <ja...@gmail.com>.
Hi Marcus,
Yes, I think that is a good idea.
Regarding the configuration: I think we still want to be able to login to
Google via either/both Custos and PSA, is that still the case? if so, I
think your previous configuration would make more sense where you had
"<provider name="Google" implementation="Custos">" specifying the IdP name
and the implementation that interfaces that IdP.
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, Mar 7, 2019 at 8:50 AM Christie, Marcus Aaron <ma...@iu.edu>
wrote:
> Hi Vahid,
>
> On Feb 28, 2019, at 7:13 PM, Vahid Jalili <ja...@gmail.com> wrote:
>
> We did not discuss the naming, "oidc" vs "keycloak" or "custos". Shall we
> postpone it to Tuesday or prefer to follow in this thread?
>
>
> Based on our discussion I think it makes sense to use more specific naming
> and use "custos". Specifically I propose:
>
> - in config/oidc_backends_config.xml the name of the backend is "Custos".
> Implementation would be "Custos" as well although with this approach
> perhaps the backend of "Custos" could imply the appropriate implementation
> (likewise, backend of "Google" would imply the PSA implementation).
> Configuration would be simplified to:
>
> <provider name="Custos">
> <client_id>...</client_id>
> <client_secret>...</client_secret>
> <redirect_uri>
> http://localhost:8000/authnz/custos/callback</redirect_uri>
> <realm>...</realm>
> </provider>
>
> - IdentityProvider implementation would be called CustosAuthnz
> in lib/galaxy/authnz/custos_authnz.py
>
> - model/database table oidc_token would be renamed to custos_authnz_token
>
> Thoughts?
>
>
> Thanks,
>
> Marcus
>
Re: custos integration with Galaxy via PSA
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
Hi Vahid,
> On Feb 28, 2019, at 7:13 PM, Vahid Jalili <ja...@gmail.com> wrote:
>
> We did not discuss the naming, "oidc" vs "keycloak" or "custos". Shall we
> postpone it to Tuesday or prefer to follow in this thread?
Based on our discussion I think it makes sense to use more specific naming and use "custos". Specifically I propose:
- in config/oidc_backends_config.xml the name of the backend is "Custos". Implementation would be "Custos" as well although with this approach perhaps the backend of "Custos" could imply the appropriate implementation (likewise, backend of "Google" would imply the PSA implementation). Configuration would be simplified to:
<provider name="Custos">
<client_id>...</client_id>
<client_secret>...</client_secret>
<redirect_uri>http://localhost:8000/authnz/custos/callback</redirect_uri> <http://localhost:8000/authnz/custos/callback%3C/redirect_uri%3E>
<realm>...</realm>
</provider>
- IdentityProvider implementation would be called CustosAuthnz in lib/galaxy/authnz/custos_authnz.py
- model/database table oidc_token would be renamed to custos_authnz_token
Thoughts?
Thanks,
Marcus
OIDC client management API available
Posted by Jeff Gaynor <ga...@illinois.edu>.
Hi!
We now have a basic implementation of the OIDC Client management
protocol up and running at https://polod.ncsa.illinois.edu/oauth2/oidc-cm.
You will need to get an administrative client to use it, which I can
create if you let me know.
There is a simple command line script to create a client. Please read
the comments in
https://github.com/ncsa/OA4MP/blob/master/oa4mp-server-admin-oauth2/src/main/scripts/oidc-cm-scripts/cm-run.sh
for how to run it. Feel free to kick the tires and give us feedback on
anything you think of.
Thanks!
Jeff
Re: custos integration with Galaxy via PSA
Posted by Vahid Jalili <ja...@gmail.com>.
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 <
thejaka.amila@gmail.com> 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 <ja...@gmail.com>
> 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 <ma...@iu.edu>
> > 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 <ja...@gmail.com>
> > > 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
>
Re: custos integration with Galaxy via PSA
Posted by Thejaka Amila J Kanewala <th...@gmail.com>.
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 <ja...@gmail.com> 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 <ma...@iu.edu>
> 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 <ja...@gmail.com>
> > 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