This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] NWIs update
- Previous message (by thread): [db-wg] NWIs update
- Next message (by thread): [db-wg] NWIs update
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tim Bruijnzeels
tim at nlnetlabs.nl
Wed Apr 10 14:29:03 CEST 2019
Hi Cynthia > On 10 Apr 2019, at 14:14, Cynthia Revström <me at cynthia.re> wrote: > > Hi, > > On 2019-04-10 13:14, Tim Bruijnzeels via db-wg wrote: >> Hi, >> >> auth-sso contains an identifier of an RIPE NCC Access SSO account. Actual details such as the email address and password are not stored in the RIPE DB. >> >> To me it would make sense to have a similar approach for API Tokens. Have some identifier that is kept on the MNTNER object, but store the actual sensitive data in a separate system. This would also allow future flexibility regarding which hashing and/or encryption to use. Essentially this would be an implementation detail that the RIPE NCC can look at, but which would not affect the whois as such. >> >> Tim > > Well there are 2 issues that I can see with this immediately, > > 1. as Denis has already mentioned a few months ago, the DB can not depend on the LIR portal being up due to it having less uptime. You are not dependent on the LIR Portal being up, you are dependent on the SSO system being up. While this introduces an extra system, it's far less complex than all of the LIR Portal. But yes having two systems is the price you pay for separating your authentication service (i.e. the need to store this data) from the authorisation being done in the database. > 2. What about people using the RIPE DB but are not LIRs, such as people/companies with PI resources? Anyone can create an SSO account, not just members. Presumably a similar thing could be done for tokens. But in any case.. I don't have a real stake in this - I just felt I should mention it as an option. > > I don't really see a way to get around issue 1. Unless we are considering doing something like signed API messages, via PGP or something. > > - Cynthia
- Previous message (by thread): [db-wg] NWIs update
- Next message (by thread): [db-wg] NWIs update
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]