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:

It already contains long discussion on the topics with some ideas. We still
miss the horsepower to actually add support for it though.


Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to