PeeringDB as an OAuth provider

[job]

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]

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]

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]

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]

@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]

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]

@baloo thanks, already done :)

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