On Wed, Oct 19, 2011 at 09:43:02AM -0400, Stephen Gallagher wrote: > On Tue, 2011-10-18 at 15:36 -0700, Toshio Kuratomi wrote: > > > > 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? > > > > 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. > Note -- not just per-application. Also per-user and per-group. sysadmin-main might be required to use 2 factors to authenticate. The other groups have more possibilities -- would we require two-factors if they have a second factor registered? Would we require just the non-password factor? Would we allow either the factor? In any case, we would have to allow password-only if the user in question did not have a second credential registered while we would likely need to allow (or mandate) two-factor for the same application if the user did have a second credential registered. If we move away from pure-ssh keys to login to hosts, pkgs.fedoraproject.org and fedorahosted.org would be very interesting environments in this regard as they need people from groups that we'd mandate to have two-factor and groups that we wouldn't mandate to have two factor to login. Currently, we use ssh keys to login and ssl certs for authn to upload to the lookaside cache. If we stick with that, that may be easier as then we'd only be changing auth for sudo. > 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). > So here's where I tell you that ricky and mmcgrath were the two people who worked on fas2 when they thought they could base it on LDAP. I only came into the picture when they decided it couldn't be made to work with LDAP and needed to use a database instead. In other words, currently, we don't have any LDAP programming expertise on the infrastructure team. So we're unlikely to be any help to you :-( > 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). So we might want to allow some of that to be done without admin intervention. As I say, we do not have the ability to do proper verification over the majority of our account holders. With that in mind, we have two choices -- refuse them access, so they have to create a new account or allow them to change token with minimal verification. If the latter, then there's no need for admin's to be involved. -Toshio
Attachment:
pgpZEexGBdbfY.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
