<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 8/2/11 4:27 PM, Dmitri Pal wrote: <blockquote class=" cite" id="mid_4E385D9B_8010207_redhat_com" cite="mid:4E385D9B.8010207@redhat.com" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: <blockquote class=" cite" id="mid_4E383ED7_1030506_hkl_hms_harvard_edu" cite="mid:4E383ED7.1030506@hkl.hms.harvard.edu" type="cite"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, X.509) in FreeIPA, tied to a user account, so only the user (via kerb token or with password prompt) can fetch the token? If FreeIPA doesn't make this possible, can anyone suggest a good mechanism to have, effectively, a user keystore that would sync passwords with FreeIPA nicely. I am thinking, in particular, of the scenario where users forget their password -- we'd strongly prefer to just reset it for them (24 hours, one login) in a way that didn't mean also re-issuing all passphrase-secured identity tokens. </blockquote> Not now however: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/754">https://fedorahosted.org/freeipa/ticket/754</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/237">https://fedorahosted.org/freeipa/ticket/237</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/521">https://fedorahosted.org/freeipa/ticket/521</a> There are also some thoughts and ideas about IPA as a secure vault for other credentials in other systems which is not logged as a ticket. Would you mind sharing with us your ideas about this functionality actually should work? Use cases, examples and design ideas are very welcome.</blockquote> Is there any standard to keystores? It would be great if Linux, Mac, Windows could all be pointed at an FreeIPA to fetch credentials, usernames, passwords. Authentication could use kerberos tickets if available, otherwise prompt for username/password, or have configurable authentication policies. Users and administrators could set ACL policies on the keystores (I know very little about LDAP, but I believe LDAP already provides this kind of thing), and they could be hierarchical, with access policy inheritance. It could act as a password safe like <a class="moz-txt-link-freetext" href="http://kedpm.sourceforge.net/">http://kedpm.sourceforge.net/</a>. Imagine storing SSH private keys in IPA. The user then wants to fetch these into ssh-agent, or to provide them for some other in-memory process that requires access to the unencrypted private-key. Another scenario is X.509 PKI where the private key is usually passphrase encrypted. If the user forgets their passphrase, the PKI token needs to be revoked and a new one issued. Much better (IMO) to hold it in a trusted authentication system and to provide the unencrypted key to applications on demand. User-passphrase can then be linked to FreeIPA system. Here is a quick idea of a command line to fetch credentials from an IPA keystore: ipa-keystore-fetch [-k keystore] [-u username] [-p password] [-P] [-o output_dir_or_file] \ [/path/to/token/]token_name[#attribute] \ [[/path/to/token/]token_name[#attribute]] [ ... ] Usual kind of thing: the user would have a default keystore, and their kerberos tokens (if available) would be used to authenticate for access to the keystore (based on username, I guess). Users could just dump tokens in the "root" space, or arrange the tokens hierarchically. Tokens could have attributes associated with them, with a "primary" or "default" token if none is specified. Tokens could be dumped to screen, routed to an application (pipe, IPC, socket, PID), or written to file. You could pretty easily imagine commands: chmod # acl changes add edit rm backup ls Ian </body> </html>