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 _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
