New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OAuth against PeeringDB #322

Open
barryo opened this Issue May 3, 2017 · 1 comment

Comments

Projects
None yet
1 participant
@barryo
Copy link
Member

barryo commented May 3, 2017

See peeringdb/peeringdb#131

Holding / tracking ticket for IXP Manager development / issues / discussion on this.

@will-h @job @nickhilliard @grizz

@barryo

This comment has been minimized.

Copy link
Member

barryo commented Nov 7, 2017

My initial thoughts on this:

We're assuming PeeringDB implements OAuth2. Just for everyone who is not up to speed on this - here's a very simple overview and shared terminology:

  • https://aaronparecki.com/oauth-2-simplified/

  • The Third-Party Application: "Client" - a specific instance of IXP Manager (e.g. INEX's). Big NB: when I say 'IXP Manager @ INEX' below, I mean INEX's specific installation and configuration. This can be anyone's unique install - but it is explicitly not IXP Manager 'out of the box'. It's unique to each IXP.

  • The API: "Resource Server" & The Authorization Server: PeeringDB. Up to you whether these are different or the same.

  • The User: "Resource Owner": a peeringDB user who wants to access 'IXP Manager @ INEX'.

From IXP Manager's end, I see the standard login box or a 'Login using PeeringDB' (assuming said option has been enabled in the specific IXP Manager instance). I'm sure we all know what I'm talking about but image attached for clarity:

screen shot 2017-11-06 at 18 58 48

To make this work, third party applications like 'IXP Manager @ INEX' will need to register with PeeringDB and get a client ID and secret. Probably also provide a name ('INEX IXP Manager'), an icon (INEX logo) and an explanatory note. When The User is redirected from 'IXP Manager @ INEX' to PeeringDB and asks to allow 'IXP Manager @ INEX' access to their data (detailed below), the logo, name and explanatory note should be displayed. This is pretty much standard practice.

'IXP Manager @ INEX' would then receive an AUTH_CODE in the redirect back from PeeringDB. Using this AUTH_CODE, 'IXP Manager @ INEX' would talk directly to PeeringDB and exchange this for authorization code.

  • PeeringDB would record the fact that 'IXP Manager @ INEX' has been given access so the next time the flow is seamless.
  • 'IXP Manager @ INEX' would create (or update) the local user with the PeeringDB authorization code

PeeringDB should not allow OAuth2 until the user's email has been confirmed.

From PeeringDB, 'IXP Manager @ INEX' would need the user's:

  • email address
  • list of associated ASNs with user group (read/write matches member/admin?) for each

Then IXP Manager would grant this user access to any customer(s) on IXP Manager with matching ASNs.

[on IXP Manager, we will put knobs that will allow an IXP or network to opt out of this on a case by case basis]

As part of this, I'll write a PeeringDB provider for Socialite: https://socialiteproviders.github.io/

Totally ignoring refresh tokens, etc for now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment