> > * Could we require someone enter their password + token before accepting > > the token? ie, they try and enroll, ipa adds it, they have to verify, if > > they can't, it's removed? > > This is _very_ common in other implementations. Yeah, but there is no API in IPA to do that (we did consider it when writing the code). I've been working on this issue yesterday, trying to find a workaround, but my tests didn't give something usable. I've asked the FreeIPA folks on IRC and they had no solution (but they had meetings, so maybe later). I've noticed that Christian proposed a possible (hackish) way of doing it yesterday evening in the AAA channel, I'll try that on Monday. > > * Could we add 'recovery codes' so if someone enrolls and it's > > wrong/broken, they could use a code to login and add a new token and > > remove the old broken one? > > Likewise! Again, there is no API in IPA to do that. Christian suggested a workaround where we could use a HOTP token to get a similar result, however the user would still need to enroll the hotp token, so if they can't enroll their TOTP or if it fails, there's little chance enrolling the HOTP token will not fail as well. > > 2. How can we verify identity on people who request the removal of their > > last otp? Do we just tell them to make a new account? > > > > Random ideas: > > > > * If they are not in any groups, how about we just reset based on email? > > * Or perhaps if they are not in any sysadmin* groups? > > I think packager groups should also not be reset just based on email. I can log the creation of OTP tokens in Noggin, and we could maybe decide that if you ask us to delete a token you've created in the last 20 minutes, we do it based on email? > > * If they are Red Hat employees we can use the internal verify thing > > Yes. Is there a way we could extend something similar to non-RHers? That would be interesting, how does it work? Can we replicate it in some way? > > * We could use gpg signed email if there is a gpg key assigned to the > > account. > > * Could we use ssh key to verify them? Like asking them to edit a file on people.fp.o? But I suppose not everybody will have an ssh key either. A. _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
