OpenID Connect

[bufferoverflow]

There is a growing amount of authentication providers with OpenID Connect support , see e.g. http://openid.net/certification/

Are there any plans on providing generic OpenID Connect support instead of adding individual providers?

[toupeira]

There's sentry-auth-google which already uses Google's OIC flow, it looks like I can generalize it a bit to make it work with any OIC provider.

@dcramer does that sound like a sensible approach, i.e. make a new plugin sentry-auth-openid-connect? Or are you maybe planning to migrate to the new python-social-auth?

[dcramer]

1. auth providers are for single sing-on, its not convience auth, which means certain security concerns need adressed
2. outside of saml/ldap, we have no intention to add any additional providers at this time
3. we have no intention to use newer social_auth, and the version we're using is now
   a) used for sso
   b) resemebling the upstream version (we forked and vendored it)
   c) will eventually be removed from our codebase in favor of our own implementation

[toupeira]

@dcramer thanks for the information! Not sure what you mean by "convenience auth" though, OpenID Connect was built for SSO as well.

But just to clarify: it's possible to implement this as a standalone plugin similar to sentry-auth-google, right? We don't particularly mind if it's not bundled with Sentry itself.

[dcramer]

@toupeira its more the fact that most auth providers aren't really intended for the kind of security we're asking for. Even GitHub is a little problematic, and although what we need can be accomplished via orgs + teams, it's not really their primary goal at the end of the day. Google is the only real mainstream auth provider beyond SAML at this point, and that's definitely what we recommend.

[toupeira]

@dcramer not sure what you think is problematic security-wise with OIC, can you elaborate? It's pretty much a modern replacement for SAML, and again Google is using OIC as well.

[dcramer]

It's not the protocol (which provides very little afaik) it's the service provider.

We need providers that:

• aren't going to easily be compromised
• provide at minimum acl management via groups
• can in realtime be utilized for revocations of access ideally via push but pull is also required

[max-wittig]

@dcramer I think you're mistaking OpenID Connect with OpenID (confusing naming...).

Using OpenID Connect, you can actually define providers, as application. It's just a standardarization layer on top of OAuth2 standardization. Advantage is that you don't need another library for another OAuth2 service, which supports OIC.

[dcramer]

Either way what I said remains true. We don’t want arbitrary oauth services which may or may not be trusted to act as authentication sources. SAML is an exception to this but we tighten the rules around it and consider it a necessary evil.

[max-wittig]

I feel like you still don't understand OpenID Connect. It's not arbitrary. You can define allowed providers. It's just a standard for identification.
It's like saying the HTTP protocol is dangerous, because there are so many malicious websites one can visit.

[toupeira]

To elaborate a bit further: OpenID Connect can be used with on-premises installations of provider implementations like GitLab or Keycloak, which are inherently more trustworthy than any external service provider. Both of these also support group ACLs and revocation.

[Sirius-A]

For people also looking for this feature, here is a fork with full oidc integration: https://github.com/siemens/sentry-auth-oidc

[fungiboletus]

Having an officially maintained OAuth2 plugin would be great to have. Having to maintain user accounts and credentials in various place is a security risk.

[mingfang]

can we reopen this issue?
we need this.