On 02/19/2015 01:06 AM, Martin Minkus wrote: > Hello all, > > Am wondering what support FreeIPA has for Application Specific > Passwords? My research seems to indicate 'none'. I've seen quite a few > people ask about this, usually the example is wanting a separate > password for dovecot etc. > > Google itself implemented this, allowing multiple passwords for imap > accounts in gmail so that a stolen phone or ipad doesn't give the thief > complete unfettered access to the entire google account. The single > password can be easily changed or locked out and even if it is not, it > only has access to email. > > I work for an organisation and we are looking at standardising on > FreeIPA for all our single sign on and auth requirements. > > Except where we don't want single sign on, and separate passwords are > advantageous or even required: > > - Web logins > - VPN logins > - Tacacs > > I'm assuming it's somewhat understandable to want to keep web logins > separate - web sites are notoriously insecure, and we wouldn't want an > employee's web login getting stolen/phished/etc giving an attacker vpn > access, kerberos/ldap access to all our linux servers, and tacacs access > to network infrastructure.
I am not sure what exactly is the fear here. If FreeIPA Web Authentication modules are used (http://www.freeipa.org/page/Web_App_Authentication), the user credentials are not stored on the web server, they go straight to SSSD where the user get's authenticated to remote LDAP (FreeIPA/AD). Alternatively, you could also set up SAML with mod_auth_mellon and Ipsilon to get a federated login where the web app would never get to the actual password. > The solution I've seen suggested to others that have asked about FreeIPA > or OpenLDAP and Application Specific Passwords seems to be: Just create > a separate user login for each application. > > Messy, but sure. > > I also see we could extend the schema and add in extra fields like > webPassword and vpnPassword, but we'd have to maintain those > fields/enforce complexity and length requirements/password expiry > ourselves which is less than ideal. > > Or the final option might just be to run separate ldap instances for > each application, so the username stays the same group membership is > application specific in each ldap instance, and it gives us the password > separation we desire. Also, most users don't need tacacs access or vpn > access, though most(all) users will need web application access. > > Anyway. I'm wondering if there are any other potential options that I > have missed? Or some better way we should be going about this? > > Yeah, we should probably trust our employees with their passwords more > but apparently that is not the case. > > Thanks, > Martin. I think we have exactly this request tracked: https://fedorahosted.org/freeipa/ticket/4510 It already contains long discussion on the topics with some ideas. We still miss the horsepower to actually add support for it though. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project