personalised authorisation - ripe69.ripe.net · •maintainers are anonymous-complicates recover...

RIPE 69 | London - United Kingdom | 6 November 2014

Personalised Authorisation

Tim Bruijnzeels Assistant Manager Database Group

Tim Bruĳnzeels - RIPE 69 - 06/11/2014

• Maintainers and Persons are hard!- Lots of support requests- Maintainer reset process- People confused at training courses!

• User experience and tools suffer- Complicated object creation and maintenance- Complicated set up for new LIRs- Complicated authorization management

2Why is the RIPE NCC concerned with this?


• WG feedback needed!

3Disclaimer


• Person objects MUST be maintained- So we recommend people to use their own maintainer- And since this is cumbersome to set up, we have a tool

https://apps.db.ripe.net/startup/

• We also have SSO accounts- Another (private) identity for users to maintain- Used in more and more places- Provides authentication (two-factor optional)- Easy password recovery

4Person objects are hard!

https://apps.db.ripe.net/startup/


mntner: tim-br-mnt descr: Startup maintainer admin-c: TB7733-RIPE upd-to: [email protected] auth: MD5-PW # Filtered mnt-by: tim-br-mnt referral-by: tim-br-mnt changed: [email protected] 20141024 source: RIPE # Filtered

5

person: Tim Bruijnzeels address: Singel 258 1016 AB Amsterdam Netherlands phone: +31205354444 e-mail: [email protected] nic-hdl: TB7733-RIPE mnt-by: TB7733-RIPE auth: SSO auth: PGP changed: [email protected] 20141024 source: RIPE

Self-maintaining persons and SSO


• Maintainers are anonymous- Complicates recover access to a maintainer if password is lost- Updates are accepted as long the authentication provided matches any of

the authentication values, on any of the maintainersComplicates showing sensible update logs to authorized users !

• Maintainers are not intuitive- Contrary to other RIPE DB objects it is not clear what exactly a maintainer

represents (person, organisation, group, script)- Most security systems use an approach that separates authentication (who

you are), from authorization (what you are allowed to do), and groups individuals in roles:My colleagues and I (authenticated persons) are part of a group (role) that is authorised to maintain this object (mnt-*)

6Maintainers are hard!


object

7Maintainers are hard!

admin-c tech-c mnt-*

mntner

auth-green? auth-purple? auth-black?

role

admin-c admin-c

person

name: mr. purple

person

name: ms. green

person

name: dr. bluedirect reference to person without role discouraged because of poor scaling

No idea which auth is owned by whom


role

admin-c admin-c !

tech-c !

auth-c auth-c

object

8Refer to roles with persons everywhere...

admin-c tech-c mnt-*

person

name: mr. purple

person

name: ms. green auth: sso

person

name: dr. blue auth: sso auth: pgp

+

-

Consistent with how we do other groups of persons

More difficult migration path (will get back on this)


role

admin-c admin-c !

tech-c

object

9Or.. have persons in maintainers

admin-c tech-c !

mnt-*

person

name: mr. purple

person


person


mntner

auth-c auth-c

+

-

Easier migration path

Having roles for groups of contact persons, and mntner for groups of authorised persons may be confusing


• Keep different mechanisms?- Adds complexity and confusion

• Create new, and delete old some time later?- We have 50k maintainers.. there is no way we will get everyone

to update!

• Should remain compatible at all times- No action should be required from current users- I.e. any forced migration should be fully automatable- Everything should keep working- Improvements available to new and existing users

10What about existing maintainers?


• Updates include credentials (password, pgp, etc), but do not mention which maintainer is supposed to contains them!

• The software checks all eligible maintainers for a match!

• The software can still easily find matches by checking roles and persons, or persons on maintainers, instead of just maintainersIn short: nothing needs to change here..

11What about existing tools?


12

mntner

auth*

role

auth-c*authorise

person

person

auth*

Convert most of the mntner into a role with the same name

Move all auth lines into a single anonymous person

Migrating existing maintainers to roles?

But how do we deal with all the attributes?


13Attributes in maintainer not found in role

attr mandatory or optional? problem?

mntner lookup key (name) 364 out of 50055 clashes

descr mandatory make optional in role

upd-to mandatory make required when role is used to maintain

mnt-nfy optional make optional when role is used to maintain

auth mandatory use auth-c in role and allow auth in person

referral-by mandatory will be removed

i) Should be possible to fix case by case.ii) This might be useful in roles anyway.iii) We will need these anyway if a role is used in a maintainer context. And we can have business rules

to ensure that they are set when needed.iv) Implement business rules to require that auth-c is present when using a role in a maintainer context,

and that auth is present in persons referenced.Filter “auth-c:” from normal output! Similar to “auth:” now, this is nobody’s business but yours.


14Attributes in role not found in maintainer

attr mandatory or optional? problem?

address mandatory use ‘unknown’? make ‘optional’?

phone optional leave blank

fax-no optional leave blank

e-mail mandatory use ‘upd-to’? ‘unknown’? make ‘optional’?

nic-hdl mandatory auto-generate


15Anonymous persons?

attr problem?

person generate anonymous-person-for-roleX

address use ‘not applicable’

phone use ‘not applicable’

nic-hdl auto-generate

mnt-by allow self maintaining

remarks anonymous person object for role X, see: http://www.ripe.net/…/documentation/…

• Filter from normal queries? This is not of general interest.. authorized users that know the “auth-c:” in the role, can find it by nic-hdl.

• Do not allow updates? Encourage setting up proper persons (with tooling)?• Or is there a more general use? A ‘person’ object for your organisation, to

support automated tools?

http://www.ripe.net/%E2%80%A6/documentation/


16or.. just adding optional persons to maintainers..person


person


mntner

auth auth !

auth-c auth-c

• No migration needed for current maintainers

• No anonymous persons, maintainer is still the logical point for scripts

• But allows referring to natural persons where possible

• Allows easy automatic migration of current “auth: sso” to “auth-c: person” once the person has its own “auth: sso”


Next steps?

• WG discusses

• Consensus!

• RIPE NCC provides implementation plan!

• WG discusses!

• Consensus!

• RIPE NCC implements

17

Questions?


18

personalised authorisation - ripe69.ripe.net · •maintainers are anonymous-complicates recover...

Documents