On Tue, 2011-10-18 at 15:36 -0700, Toshio Kuratomi wrote: > On Tue, Oct 18, 2011 at 08:19:28AM -0400, Stephen Gallagher wrote: > > > > It might be worth revisiting the discussion about a potential FAS3 built > > atop the upcoming FreeIPA v3 (which will have this support). > > We discussed on IRC the blockers for this. Hopefully at FUDCon the > immediately known blockers will have been resolved and we'll get a demo of > what a system with freeipa could look like. > > Once question that popped into my mind right now is will we have the ability > to specify that different groups and different users have different > requirements/access methods? > > In the talks that we've had so far... it looks like we're desiring something > similar to this: > > sysasmin-main and possibly sysadmin* => Mandatory two factor. Password > + any supported otp solution (yubikey or some otp via android). > > all others non-mandatory two-factor. Same technologies as above. User > selects whether to make two-factor mandatory or not. > > May need to allow single factor to login at times in the web application as > well -- this is a big unknown. If someone loses half of their two-factor > auth, how are we going to reset their account. For sysadmin-main, we figure > the pool is small enough that we can call each other or otherwise arrange > some way to verify that the person is really who we think they are. So it > would be manually verify and manually reset. For other Fedora groups, the > knowledge we have of a person and their connections to others inside Fedora > Infrastructure is much less. It may be that for some of those groups we > allow them to reset their own 2nd factor auth with only a single factor > (after all, we're allowing their colleagues to use only a single factor all > the time).... We've been talking about how to handle this. We haven't really touched on the idea of requiring a different level of assurance for different applications, but we are aware of the "lost token" problem. The current plan is for us to store an attribute with the user's challenge requirements in the user's LDAP entry (with appropriate ACLs to make it difficult for an attacker to learn). Right now we only have plans for a single method, but if you think that method->application mappings are necessary, please speak up (and preferably help propose a mechanism to store that information in LDAP). As for "lost token", the idea would be that the admin would be able to reset the user's login requirements to password or similar until a new token can be mailed out. (Leaving it up to the admin to perform proper verification that the token was actually lost vs. a social-engineering attempt).
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
