On Mon, 2011-10-17 at 16:54 -0600, Kevin Fenzi wrote:
So, there's a lot of data here and info to process. ;)
Some things (in no particular order):
I think we have the following groups to consider:
1. Sysadmin-main folks who can sudo and login to everything.
(small. ~10-20)
2. Sysadmin* folks who can login to some things and sudo on some things
(a number of small groups, total ~120ish ).
3. packagers ( larger group, ~1100 ish).
4. cla+1group, fedorapeople, etc (larger yet, ~2500).
5. web application users (testers, election voters, account sys,
mirrormanager). ( larger group still)
I think the amount of hassle people will put up with increases as we go
down the list, but also the amount of sensitive access decreases. I'm
not sure we will have much luck pushing things down past the first few
groups unless we make it VERY easy to use and manage and make sure
there are no costs.
I agree with that assessment except I think you meant 'decreases' not
increases in the first clause of your paragraph above.
Does the yubikey OATH mode work with linotp/googleauth?
From what I can see it should. So, perhaps we can support both?
I think it should be possible - it will require some effort. Also it
will increase the complexity of what we have to support.
I'm a bit leary of linotp having a 'community' and
'enterprise'
edition, and some of the features in the enterprise we would need to
re-implement.
1. we don't need to use linotp AT all - I wasn't suggesting we should
use it.
2. the part of linotp that is useful is their pam module and how it
works.
On the other hand google-authenticator doesn't have any server
ability
yet. ;( I did notice this stalled review:
https://bugzilla.redhat.com/show_bug.cgi?id=538327
for otpd that might be worth looking at.
That's what I was talking about - linotp's pam module gets us to the
point where we can talk to a server for validating the otps.
Ideally, I'd love to see a solution like the duo-security one,
but of
course opensource and where we run all the parts of it (not a 3rd
party).
Duosecurity's mechanism will REQUIRE an internet-connected android or
ios device. There is no way around that. If we mandate that as required
then we can pursue an entirely different route. Also - there is nothing
in what I'm suggesting here that precludes us from pursuing that route -
it is just a fair amount more work b/c of the phone app [re]writing
that's necessary.
I sure wonder if other open source groups would be interested in
getting something together, since I think a lot of them have similar
groups to handle.
on the one hand - sure - I suspect they will
on the otherhand - any effort to do that will be an enormous ass pain to
coordinate. If we wanted to pursue such a thing I'd want to start by
having something working to bring to a group of people and letting it
get refined by normal processes. Not starting with an idea and going
from there.
My current plan is to test out pam_linotp and see if I can make it work
w/a different cgi on the backend. If I can then I can see about grafting
a working tool together as a starting point.
Ideally one that can accept otp from google-authenticator AND (if I can
find the damn tools) yubikey auths.
-sv