Skip to content
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

PeeringDB as an OAuth provider #131

Closed
job opened this issue Mar 6, 2017 · 6 comments
Closed

PeeringDB as an OAuth provider #131

job opened this issue Mar 6, 2017 · 6 comments
Assignees
Labels
Time:Major 4 - 10 hours work
Milestone

Comments

@job
Copy link
Contributor

job commented Mar 6, 2017

Proposal

PeeringDB users are often connected to multiple internet exchanges and congregate at the same events, it would perhaps be in the interest of all stakeholders involved (both ISPs and IXPs) to let PeeringDB be an OAuth provider. This way people can use their PeeringDB account to login to various event- or IXP portals.

For technical guidance, we should end up implementing something similar to how tripit.com/jetitup.com interact with each other. See http://tripit.github.io/api/doc/v1/#authentication_section and scroll down to OAuth.

@will-h
Copy link

will-h commented Mar 7, 2017

At LONAP we spend quite a lot of time with user account problems e.g. 'ZYX has left the company, please delete their account' and so on. I think this work could save quite a lot of effort for multiple organisations.

I think the work has three strands:

  1. Consideration of design, protocol choice, and policy (how would networks turn it on? what class of user is permitted to do what?)

  2. Implementation of necessary interface into Peeringdb to authenticate users.

  3. Implementation of reference interface to an IXPs portal software, for example IXPManager.

@grizz
Copy link
Member

grizz commented Nov 23, 2017

Have this working in development, based largely on OpenID Connect.

Scopes currently are defined as profile, email (which adds email and verified_email), and networks (which adds networks).

Perms field is a bitmask for CRUD as the 4 LSBs.

Example for my user:

{
  "family_name": "Griswold", 
  "email": "grizz@20c.com", 
  "name": "Matt Griswold", 
  "verified_user": true, 
  "verified_email": true, 
  "networks": [
    {
      "perms": 15, 
      "autnum": 63311, 
      "name": "20C", 
      "id": 20
    }, 
    {
      "perms": 15, 
      "autnum": 33713, 
      "name": "United IX", 
      "id": 7889
    }
  ], 
  "id": 3, 
  "given_name": "Matt"
}

Does anyone have feedback on this?

@mahtin
Copy link

mahtin commented Nov 24, 2017

Question: Why pick only some fields for "networks": [ ... ] section? Isn't just the "id" enough? I thought it should be either an all-or-nothing thing. If you need more than "id" then add them all.

Plus ASN field should match name used elsewhere ("autnum" -> "asn"). I don't know about the user info field names (like "given_name" etc).

FYI: The API call for your network produces:

{ "data": [ { "aka": "", "asn": 63311, "created": "2014-11-17T14:59:34Z", "id": 20, "info_ipv6": true, "info_multicast": false, "info_prefixes4": 200, "info_prefixes6": 50, "info_ratio": "Balanced", "info_scope": "Global", "info_traffic": "", "info_type": "Enterprise", "info_unicast": true, "irr_as_set": "AS-20C", "looking_glass": "", "name": "20C", "netfac_set": [ ... ], "netixlan_set": [ ... ], "notes": "", "org": { ... }, "org_id": 10356, "poc_set": [ ... ], "policy_contracts": "Not Required", "policy_general": "Selective", "policy_locations": "Not Required", "policy_ratio": false, "policy_url": "", "route_server": "", "status": "ok", "updated": "2017-03-16T05:11:35Z", "website": "http://20c.com" } ], "meta": { ... } }

@grizz
Copy link
Member

grizz commented Nov 26, 2017

@mahtin Thanks for the feedback.

Question: Why pick only some fields for "networks": [ ... ] section? Isn't just the "id" enough? I thought it should be either an all-or-nothing thing. If you need more than "id" then add them all.

Started with just having asn -- added id and name just for ease of use. I think putting all fields here would be drastic overkill, anyone wanting all of them should have PDB synced locally.

Plus ASN field should match name used elsewhere ("autnum" -> "asn"). I don't know about the user info field names (like "given_name" etc).

Agreed on asn, will change that. user info field names are taken from OpenID Connect, so using those here makes more sense to me.

@baloo
Copy link

baloo commented Nov 26, 2017

You might want to hide email address and names behind a scope. That would be nice to auth against a service without actually sharing personal information. Github does this and you may auth against github and only get back the user id and the username (which is believe is a nice feature privacy-wise). The service may request the email address, but Github will warn about it.

@grizz
Copy link
Member

grizz commented Nov 27, 2017

@baloo thanks, already done :)

Scopes currently are defined as profile, email (which adds email and verified_email), and networks (which adds networks).

@vegu vegu added this to the Next Release milestone Jan 8, 2018
@vegu vegu closed this as completed Jan 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Time:Major 4 - 10 hours work
Projects
None yet
Development

No branches or pull requests

6 participants