Re: [Freeipa-devel] [PATCH 0008] Typo in warning message where IPA realm and domain name differ
On 03/04/2014 01:48 AM, Simo Sorce wrote: On Mon, 2014-03-03 at 17:20 -0700, Gabe Alford wrote: Hi all, Quick one line change to fix. https://fedorahosted.org/freeipa/ticket/4211 ACK Simo. Pushed to master: b50cdd55af8af7fdf30a822dce03af68969ddfe6 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog
On 03/04/2014 05:56 PM, Adam Misnyovszki wrote: - Original Message - From: Adam Misnyovszki amisn...@redhat.com To: Petr Vobornik pvobo...@redhat.com Cc: freeipa-devel freeipa-devel@redhat.com Sent: Tuesday, March 4, 2014 5:27:21 PM Subject: Re: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog - Original Message - From: Petr Vobornik pvobo...@redhat.com To: freeipa-devel freeipa-devel@redhat.com Sent: Tuesday, February 25, 2014 2:20:11 PM Subject: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog Fixes issue when: 1. 2 dialogs are opened 2. top dialog's close button is focused 3. user presses enter to execute 'close' action 4. dialog is immediately closed (enter key is still pressed) 5. second dialog automatically receives focus (it's top dialog now) 6. user releases the key 7. second dialog reacts to keyup event - which is by default confirmation mixin's confirm event 8. UNDESIRED behavior occurs Now confirmation mixin remembers which keys were pressed and released and reacts only to those which originated there. https://fedorahosted.org/freeipa/ticket/4098 -- Petr Vobornik ACK However, we should keep in mind, that there is an issue, when the ENTER key is pressed for a long time(ie more time than a keydown event is fired), the dialog starts to blink. In my oppinion, this later behaviour is a wontfix, because firstly it is not easy to handle, secondly because this problem exists in mostly all softwares, thirdly this is not the scope of the ticket. Sorry for the amendment, zimbra doesn't work quite well. Adam Pushed to master: 9b540ef21864f8da822bd92d58385339147e773d -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration
On 03/04/2014 04:59 PM, Tomas Babej wrote:
Thanks,
PATCH 341: ACK
(this is the last remaining ACK for this patchset)
Also pushed to ipa-3-3: 23814f9b57794a5f2f8ae62a3342ee18535df2ea
On 03/04/2014 11:58 AM, Petr Viktorin wrote:
On 03/03/2014 01:41 PM, Tomas Babej wrote:
Finally got to this patchset!
PATCH 337: ACK
PATCH 338: ACK
This prohibits us to use extra roles that end in digits. Can you put a
note explaining that in
http://www.freeipa.org/page/V3/Integration_testing#Host_configuration
Updated.
Also, this wiki page points out to environment variables so that it
seems it is the preferred method of configuration. We should mention
more user friendly YAML here first.
Let's do that when the patches are pushed. #3938 should stay open
until it's done.
PATCH 339: ACK
PATCH 340: ACK
PATCH 341:
The have_master variable seems redundant in from_dict method (it's only
a local definition and not referenced anywhere else):
+def from_dict(cls, dct, config):
+from ipatests.test_integration.host import BaseHost
+
+domain_type = dct.pop('type')
+assert domain_type in ('IPA', 'AD')
+domain_name = dct.pop('name')
+self = cls(config, domain_name, domain_type)
+
+have_master = False
+for host_dict in dct.pop('hosts'):
+host = BaseHost.from_dict(host_dict, self)
+self.hosts.append(host)
+if host.role == 'master':
+have_master = True
+
+check_config_dict_empty(dct, 'domain %s' % domain_name)
+
+return self
Right you are. Fixed.
PATCH 342: ACK
PATCH 343: ACK
PATCH 348: ACK
PATCH 349: ACK
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration
On 03/04/2014 04:59 PM, Tomas Babej wrote:
Thanks,
PATCH 341: ACK
(this is the last remaining ACK for this patchset)
Thank you!
Pushed to master: 561e57d12169cfa4e1d2c5d9fef42b149c37fca2
On 03/04/2014 11:58 AM, Petr Viktorin wrote:
On 03/03/2014 01:41 PM, Tomas Babej wrote:
Finally got to this patchset!
PATCH 337: ACK
PATCH 338: ACK
This prohibits us to use extra roles that end in digits. Can you put a
note explaining that in
http://www.freeipa.org/page/V3/Integration_testing#Host_configuration
Updated.
Also, this wiki page points out to environment variables so that it
seems it is the preferred method of configuration. We should mention
more user friendly YAML here first.
Let's do that when the patches are pushed. #3938 should stay open
until it's done.
PATCH 339: ACK
PATCH 340: ACK
PATCH 341:
The have_master variable seems redundant in from_dict method (it's only
a local definition and not referenced anywhere else):
+def from_dict(cls, dct, config):
+from ipatests.test_integration.host import BaseHost
+
+domain_type = dct.pop('type')
+assert domain_type in ('IPA', 'AD')
+domain_name = dct.pop('name')
+self = cls(config, domain_name, domain_type)
+
+have_master = False
+for host_dict in dct.pop('hosts'):
+host = BaseHost.from_dict(host_dict, self)
+self.hosts.append(host)
+if host.role == 'master':
+have_master = True
+
+check_config_dict_empty(dct, 'domain %s' % domain_name)
+
+return self
Right you are. Fixed.
PATCH 342: ACK
PATCH 343: ACK
PATCH 348: ACK
PATCH 349: ACK
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled
On 03/03/2014 01:14 PM, Jan Cholasta wrote: On 21.2.2014 17:45, Nathaniel McCallum wrote: On Fri, 2014-02-21 at 16:29 +0100, Jan Cholasta wrote: Hi, On 21.2.2014 16:09, Nathaniel McCallum wrote: On Fri, 2014-02-21 at 09:45 -0500, Nathaniel McCallum wrote: We had originally decided to provide defaults on the server side so that they could be part of a global config for the admin. However, on further reflection, only certain defaults really make sense given the limitations of Google Authenticator. Similarly, other defaults may be token specific. Attempting to handle defaults on the server side also makes both the UI and the generated documentation unclear. NOTE: this patch changes an existing API. VERSION says that we should bump the major version in this case. But we haven't actually released this API yet. Please advise. There were similar changes in the past and bumping minor version was always enough (we never ever bump major version). Fixed. Thanks, ACK. Pushed to master: 21ff4f920e4ff7c1e2870024f007f067fc3cf6c8 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0045] Fix token secret length RFC compliance
On 03/03/2014 05:19 PM, Jan Cholasta wrote: On 3.3.2014 17:13, Nathaniel McCallum wrote: RFC 4226 states the following in section 4: R6 - The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits. ACK. Pushed to master: 0ca6653c299c75f5215cc37c6b129ce58a85e8df -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0145: trust fix filtering of users from subdomains
On 03/04/2014 05:12 PM, Simo Sorce wrote: On Tue, 2014-03-04 at 11:33 +0200, Alexander Bokovoy wrote: On Tue, 04 Mar 2014, Martin Kosek wrote: On 03/04/2014 10:13 AM, Alexander Bokovoy wrote: Attached patch should fix https://fedorahosted.org/freeipa/ticket/4207 where we didn't filter out users from disabled subdomains aggressively enough. The code that did not filter exists only in git, not in released versions yet. Attached also a screenshot that explains the behavior. The code was tested by me, Sumit, and Scott, and reviewed over last few days by Simo and Sumit. Thanks Alexander! Do I understand it right that it has an ACK from Simo and Sumit? If yes, I will push the patch to master and ipa-3-3 (when fedorahosted git starts working again). I'd like to get ACKs here, Simo didn't see the latest version yesterday. Looks good to me. Simo. Pushed to: master: 6b45ec3f31773ee7a229d5bb56675badc2d8fd55 ipa-3-3: be033fd57d818d6e90d7a4a73650bfc18d0d2c2b Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client
On Mon, Feb 24, 2014 at 02:58:13PM +0100, Tomas Babej wrote: Hi, If SSH keys have not been generated prior to enrolling the client to the IPA server, they will not be uploaded to the server, since they're not present. Clarify this issue in the man pages. https://fedorahosted.org/freeipa/ticket/4055 [...] +.SS Assumptions +The ipa\-client\-install script assumes that the machine has already generated SSH keys. It will not generate SSH keys on its own accord. I'm not native speaker but I believe it should be either on its own or of its own accord. If SSH keys are not present (e.g when running the ipa-client-install in Is it correct that there are no backslashes in this occurence of ipa-client-install? a kickstart, before ever running sshd), they will not be uploaded to the client host entry on the server. + -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client
Thanks Jan, both fixed. Tomas On 03/05/2014 10:53 AM, Jan Pazdziora wrote: On Mon, Feb 24, 2014 at 02:58:13PM +0100, Tomas Babej wrote: Hi, If SSH keys have not been generated prior to enrolling the client to the IPA server, they will not be uploaded to the server, since they're not present. Clarify this issue in the man pages. https://fedorahosted.org/freeipa/ticket/4055 [...] +.SS Assumptions +The ipa\-client\-install script assumes that the machine has already generated SSH keys. It will not generate SSH keys on its own accord. I'm not native speaker but I believe it should be either on its own or of its own accord. If SSH keys are not present (e.g when running the ipa-client-install in Is it correct that there are no backslashes in this occurence of ipa-client-install? a kickstart, before ever running sshd), they will not be uploaded to the client host entry on the server. + -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From 0da460699594565f341f7f17ee53ce1fb1b6ea44 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 27 Nov 2013 09:49:32 +0100 Subject: [PATCH] man: sshd should be run at least once before client enrollment If SSH keys have not been generated prior to enrolling the client to the IPA server, they will not be uploaded to the server, since they're not present. Clarify this issue in the man pages. https://fedorahosted.org/freeipa/ticket/4055 --- ipa-client/man/ipa-client-install.1 | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipa-client/man/ipa-client-install.1 b/ipa-client/man/ipa-client-install.1 index 51a276202ac28b630d928e70dd658fad929b8d2b..3d72b0c9f5f5c5dec6314adf9eb02f873918bfda 100644 --- a/ipa-client/man/ipa-client-install.1 +++ b/ipa-client/man/ipa-client-install.1 @@ -30,6 +30,9 @@ An authorized user is required to join a client machine to IPA. This can take th This same tool is used to unconfigure IPA and attempts to return the machine to its previous state. Part of this process is to unenroll the host from the IPA server. Unenrollment consists of disabling the prinicipal key on the IPA server so that it may be re\-enrolled. The machine principal in /etc/krb5.keytab (host/fqdn@REALM) is used to authenticate to the IPA server to unenroll itself. If this principal does not exist then unenrollment will fail and an administrator will need to disable the host principal (ipa host\-disable fqdn). +.SS Assumptions +The ipa\-client\-install script assumes that the machine has already generated SSH keys. It will not generate SSH keys of its own accord. If SSH keys are not present (e.g when running the ipa\-client\-install in a kickstart, before ever running sshd), they will not be uploaded to the client host entry on the server. + .SS Hostname Requirements Client must use a \fBstatic hostname\fR. If the machine hostname changes for example due to a dynamic hostname assignment by a DHCP server, client enrollment to IPA server breaks and user then would not be able to perform Kerberos authentication. -- 1.8.5.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client
On Wed, Mar 05, 2014 at 12:33:01PM +0100, Tomas Babej wrote: Thanks Jan, both fixed. Ack. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client
On 03/05/2014 12:37 PM, Jan Pazdziora wrote: On Wed, Mar 05, 2014 at 12:33:01PM +0100, Tomas Babej wrote: Thanks Jan, both fixed. Ack. Pushed to master: 6b94f959a4d41b62ca6c2b273633880bbfab8b49 Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Marti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter
On 25.2.2014 11:15, Tomas Babej wrote:
On 01/14/2014 10:19 AM, Petr Viktorin wrote:
On 01/14/2014 09:27 AM, Jan Cholasta wrote:
On 13.1.2014 14:57, Petr Vobornik wrote:
On 13.1.2014 13:41, Jan Cholasta wrote:
Hi,
On 10.1.2014 21:21, Nathaniel McCallum wrote:
On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote:
Hi,
Adds a parameter that represents a DateTime format using
datetime.datetime
object from python's native datetime library.
In the CLI, accepts one of the following formats:
Accepts subset of values defined by ISO 8601:
%Y-%m-%dT%H:%M:%S
%Y-%m-%dT%H:%M
'%Y%m%dT%H:%M:%S'
'%Y%m%dT%H:%M'
Also accepts LDAP Generalized time in the following format:
'%Y%m%d%H%M%SZ'
As a simplification, it does not deal with timezone info and ISO
8601
values with timezone info (+-hhmm) are rejected. Values are expected
to be in the UTC timezone.
Values are saved to LDAP as LDAP Generalized time values in the
format
'%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To
avoid
confusion, in addition to subset of ISO 8601 values, the LDAP
generalized
time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as
this
is the
format user will see on the output).
Part of: https://fedorahosted.org/freeipa/ticket/3306
The date/time syntax formats are not compliant with ISO 8601. You
stated
they are expected to be in UTC timezone, but no 'Z' is expected in
most
of them. This is not only non-standard, but would prevent you from
every
supporting local time in the future.
+1, please require the trailing Z.
I think generalized time format should be the preferred one, as it is
stored in LDAP and thus returned by commands. Also, do we really need
all of these other formats?
+1 That API should accept and always return generalized time.
But UIs(CLI, Web) should display something more human readable. Like:
%Y-%m-%dT%H:%M:%SZ or IMHO better (but not ISO 8601): %Y-%m-%d
%H:%M:%SZ
ie. 2014-03-08 14:16:55Z compared to 2014-03-08T14:16:55Z or
20140308141655Z
Both should accept input value in the same format. Usage of different
output and input formats is confusing. Thus I agree with supporting
more
input formats. Decision whether it should be done on API level or
client
level is another matter.
If you want human readable output, you have to do the conversion from
generalized time on clients. If you want to support local time and
timezones, you have to do some processing on the client as well. I would
be perfectly happy if we supported only generalized time over the wire
and did conversion from/to human readable on clients.
I has been implementing the Web UI part and I think we should also
support a formats without time component. My initial impl. supports
combinations of:
var dates = [
['-MM-DD', /^(\d{4})-(\d{2})-(\d{2})$/],
['MMDD',/^(\d{4})(\d{2})(\d{2})$/]
];
var times = [
['HH:mm:ss', /^(\d\d):(\d\d):(\d\d)Z$/],
['HH:mm', /^(\d\d):(\d\d)Z$/],
['HH', /^(\d\d)Z$/]
];
+ generalized time
['MMDDHHmmssZ',/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})Z$/]
with /( |T)/ as divider and time optional.
Both UIs should also tell the user what is the expected format (at
least
one of them). Getting incorrect format error without knowing it is
annoying.
The current code raises a ValidationError including the list of formats.
On yesterday's meeting, Simo said that on the wire and for CLI output,
we should use generalized time.
I disagree with using it for CLI ouptut, as I find generalized time
unreadable, but for the API it's the obvious choice.
I believe we should require the Z postfix in all formats, so that 1)
users are forced to be aware that it's UTC, and 2) we can
theoretically support local time in the future.
I think the supported input formats should be:
%Y%m%d%H%M%SZ (generalized time)
%Y-%m-%dT%H:%M:%SZ (ISO 8601, with seconds)
%Y-%m-%dT%H:%MZ(ISO 8601, without seconds)
%Y-%m-%dZ (ISO 8601, date only)
I also think we should accept a space instead of the T, as Petr²
said above.
Thanks for review, everybody.
* All accepted formats now require explicit Z
* Accept values with ' ' instead of T
* LDAP generalized time used on the wire with JSON
* Minor implementation fixes
Updated patch should address all the issues.
The first if statement is not necessary here, datetime values are
correctly handled in the super class:
+def _convert_scalar(self, value, index=None):
+if isinstance(value, datetime.datetime):
+return value
+elif isinstance(value, basestring):
Please use ', ' instead of just ',' as the separator to make the error
message more readable here:
+error = (_(does not match any of accepted formats: ) +
+ (','.join(self.accepted_formats)))
This if statement is not present on old clients, so the assert below
will fail on them when they receive DateTime:
+if isinstance(value, DateTime):
+return
Re: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI
On 25.2.2014 08:34, Tomas Babej wrote:
Rebased to current master.
On 01/09/2014 04:31 PM, Tomas Babej wrote:
Hi,
Adds a krbPrincipalExpiration attribute to the user class
in user.py ipalib plugin as a DateTime parameter.
Part of: https://fedorahosted.org/freeipa/ticket/3306
The patch needs to be rebased again.
I think you can drop the (UTC) here, as only values ending with Z
are now accepted for DateTime:
+label=_('Kerberos principal expiration (UTC)'),
--
Jan Cholasta
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1
On 03/03/2014 04:10 PM, Petr Viktorin wrote:
On 02/28/2014 02:47 PM, Petr Viktorin wrote:
On 02/28/2014 02:12 PM, Martin Kosek wrote:
On 02/26/2014 10:44 AM, Petr Viktorin wrote:
Hello,
Here are a few fixes/improvements, and the first part of a managed
permission
updater.
The patches should go in this order but don't need to be ACKed/pushed
all at once.
Design:
http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
This part is a preview of sorts, to get the basic mechanism and the
metadata
format reviewed before I add all of the default read permissions.
It implements the first section of Default Permission Updater in
the design;
Replacing legacy default permissions and Removing the global
anonymous read
ACI is left for later.
Metadata is added for the netgroup plugin* for starters
[...]
1) 476: Typo in test name:
+desc='Search fo rnonexisting permission with : in the
name',
Will fix.
Fixed
2) 477: do we want to log anything when permission is up to date?
+try:
+ldap.update_entry(entry)
+except errors.EmptyModlist:
+return
I don't think that's needed, after all that's the expected behavior in
all but the first upgrade.
But I'll be happy to add it if you think it would be better.
I've added a DEBUG message here.
[...]
4) I have been quite resilient to the prefixes for the permissions,
but it
seems it is the easier possible approach to fix conflicts with user
permissions
without having to check that later for every upgrade or doing more
complex
stuff like multiple RDNs or different container for system and user
permissions.
I am now just thinking about the prefixing. Now you use this name:
ipa:Read Netgroups
Would it be nicer to use:
IPA:Read Netgroups
or
IPA: Read Netgroups
or even
[IPA] Read Netgroups
? :-)
Bikeshedding time!
Everyone on the list, please chime in!
Bikeshedding results from today's meeting:
ipa: pviktori++
System: mkosek++ simo+ ab++
Builtin: simo++ pvo+
Default:
The winner is System: , so I'll go and change to that.
Done.
--
Petr³
From a4bb46871d3d1d1202e88bbbfbc8655d92ee45f3 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 12 Feb 2014 16:17:39 +0100
Subject: [PATCH] Allow indexing API object types by class
This allows code like:
from ipalib.plugins.dns import dnszone_mod
api.Command[dnszone_mod]
This form should be preferred when getting specific objects
because it ensures that the appropriate plugin is imported.
https://fedorahosted.org/freeipa/ticket/4185
---
ipalib/base.py| 15 +--
ipatests/test_ipalib/test_base.py | 12 ++--
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/ipalib/base.py b/ipalib/base.py
index 83d778fe751e66414fe34d0d3243cdae34941ad6..91259c7f3b480ffc0e70061e1efa0135ff500478 100644
--- a/ipalib/base.py
+++ b/ipalib/base.py
@@ -287,7 +287,7 @@ class NameSpace(ReadOnly):
class Member(object):
... def __init__(self, i):
... self.i = i
-... self.name = 'member%d' % i
+... self.name = self.__name__ = 'member%d' % i
... def __repr__(self):
... return 'Member(%d)' % self.i
...
@@ -378,6 +378,14 @@ class NameSpace(ReadOnly):
unsorted_ns[0]
Member(7)
+As a special extension, NameSpace objects can be indexed by objects that
+have a __name__ attribute (e.g. classes). These lookups are converted
+to lookups on the name:
+
+ class_ns = NameSpace([Member(7), Member(3), Member(5)], sort=False)
+ unsorted_ns[Member(3)]
+Member(3)
+
The `NameSpace` class is used in many places throughout freeIPA. For a few
examples, see the `plugable.API` and the `frontend.Command` classes.
@@ -447,6 +455,7 @@ def __contains__(self, name):
Return ``True`` if namespace has a member named ``name``.
+name = getattr(name, '__name__', name)
return name in self.__map
def __getitem__(self, key):
@@ -455,12 +464,14 @@ def __getitem__(self, key):
:param key: The name or index of a member, or a slice object.
+key = getattr(key, '__name__', key)
if isinstance(key, basestring):
return self.__map[key]
if type(key) in (int, slice):
return self.__members[key]
raise TypeError(
-TYPE_ERROR % ('key', (str, int, slice), key, type(key))
+TYPE_ERROR % ('key', (str, int, slice, 'object with __name__'),
+ key, type(key))
)
def __repr__(self):
diff --git a/ipatests/test_ipalib/test_base.py b/ipatests/test_ipalib/test_base.py
index ef6c180c798632cb0cebd9b6ad89caaf744d7931..0117946bc2de8cb2aa014e42e6c6569b33f0900b 100644
--- a/ipatests/test_ipalib/test_base.py
+++
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0487 ipalib.plugable: Always set the parser in bootstrap()
Hello,
This patch fixes a failing test setup where logging was configured
before the API was bootstrapped.
The __setattr__ is moved before a conditional return.
--
Petr³
From d90395f3c7dc54efda49355976155bd56dc2259d Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 5 Mar 2014 13:59:10 +0100
Subject: [PATCH] ipalib.plugable: Always set the parser in bootstrap()
In cases where logging was already configured by the time
API.bootstrap() was called, saving the argument parser was
mistakenly skipped along with the logging configuration.
Always set the argument parser on the API object.
---
ipalib/plugable.py | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 3be8bb118570e5f80853376eb8e6973b8b087e46..216f9c08a8b5d22bdb1e7853013967e8fe3f88b0 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -493,6 +493,12 @@ def bootstrap(self, parser=None, **overrides):
object.__setattr__(self, 'log_mgr', log_mgr)
log = log_mgr.root_logger
object.__setattr__(self, 'log', log)
+
+# Add the argument parser
+if not parser:
+parser = self.build_global_parser()
+object.__setattr__(self, 'parser', parser)
+
# If logging has already been configured somewhere else (like in the
# installer), don't add handlers or change levels:
if log_mgr.configure_state != 'default' or self.env.validate_api:
@@ -518,10 +524,6 @@ def bootstrap(self, parser=None, **overrides):
level=level,
format=LOGGING_FORMAT_STDERR)])
-if not parser:
-parser = self.build_global_parser()
-object.__setattr__(self, 'parser', parser)
-
# Add file handler:
if self.env.mode in ('dummy', 'unit_test'):
return # But not if in unit-test mode
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 5.3.2014 14:21, Simo Sorce wrote: On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. Sounds good. (But I must admit I was a little bit scared for a moment :-) - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. +1 The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 03.03.2014 15:24, Jan Cholasta wrote: On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? I obviously think that using the new stuff linked above would be best. It's future proof and models this comprehensively. That would allow extracting compat trust anchors to files (for crypto libraries that don't yet support looking it up trust via PKCS#11). But I understand if you're hesitant to commit to this spec that's in development (albeit already implemented). There's a third simple way to store trust, which is using standard PKCS#11. It's very limited: * Store certificates with the CKA_TRUSTED attribute set to CKA_TRUE and CKA_CERTIFICATE_CATEGORY set to 2. This method covers storing certificate authority anchors only. The above spec is a superset of this simple way of storing trust. NSS trust objects are not. So I would suggest implementing this simple mechanism and then implement the full spec later. If you want to have a call/hangout about this and discuss, I'd be happy to. Cheers, Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one
On 09/24/2013 05:34 PM, Petr Viktorin wrote: On 06/04/2013 05:48 PM, Simo Sorce wrote: On Tue, 2013-06-04 at 17:24 +0200, Petr Viktorin wrote: On 06/04/2013 02:53 PM, Simo Sorce wrote: On Tue, 2013-06-04 at 13:48 +0200, Petr Viktorin wrote: Hardcoding the in-tree location for ipa-getkeytab makes testing outside the source tree impossible. This patch makes the tests use the installed location. In other places the test suite assumes IPA is installed system-wide, even if running from the source tree. I know I frequently forget to run `make` before testing, which makes the ipa-getkeytab tests fail. So this patch would work well for me (and probably other Python devs), but I guess others might be used to `make test` checking what `make` built. C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab /usr/sbin/ipa-getkeytab` to your testing workflow? Absolutely not. Or should this be made configurable (or auto-detected)? You must not break a machine just to do make test. I often do make test, then make rpms and install rpms, I *never* directly install on my development machine or VMs, I always go through RPM in order to keep the system clean, and tests repeatable. I do the same except I never run make test on the development machine -- without IPA installed the tests don't work. ipa-getkeytab specifically do not need root to be tested so I really do not see that copying over a system path would ever be a good idea. Simo. With this version of the patch, the tests use ipa-getkeytab from $PATH, and the in-tree directory is added to PATH in make-test. Out-of-tree tests don't use make-test so they will use the system PATH. Is that OK? Sounds good to me. Simo. Ping, could someone look at this patch? It should fix 7 of the 11 failures that happen when running the test suite out of tree. Attaching a slightly updated version. Any takers? -- Petr³ From 154ddde3d3baf4cd106055beeca9bf72adc196b6 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Mon, 3 Jun 2013 15:04:58 +0200 Subject: [PATCH] Do not hardcode path to ipa-getkeytab in tests Using the in-tree binary makes testing outside the source tree impossible. Use ipa-getkeytab from $PATH, and add the directory to $PATH when running the in-tree tests. Part of the work for https://fedorahosted.org/freeipa/ticket/3654 --- ipatests/test_cmdline/cmdline.py | 13 ++--- ipatests/test_cmdline/test_ipagetkeytab.py | 2 +- make-test | 3 +++ 3 files changed, 14 insertions(+), 4 deletions(-) diff --git a/ipatests/test_cmdline/cmdline.py b/ipatests/test_cmdline/cmdline.py index 6f3541d27081f2180f3f7b1da85d7bcd42eed353..0ef0137a67d9b51fa445b0b52b2c80a2a877dd08 100644 --- a/ipatests/test_cmdline/cmdline.py +++ b/ipatests/test_cmdline/cmdline.py @@ -23,12 +23,13 @@ import nose import krbV +import distutils.spawn +import os from ipalib import api from ipalib import errors from ipatests.test_xmlrpc.xmlrpc_test import XMLRPC_test from ipaserver.plugins.ldap2 import ldap2 -from ipapython import ipautil # See if our LDAP server is up and we can talk to it over GSSAPI ccache = krbV.default_context().default_ccache() @@ -51,11 +52,17 @@ class cmdline_test(XMLRPC_test): command = '/bin/ls' def setUp(self): +# Find the executable in $PATH +# This is neded because ipautil.run resets the PATH to +# a system default. +original_command = self.command +if not os.path.isabs(self.command): +self.command = distutils.spawn.find_executable(self.command) # raise an error if the command is missing even if the remote # server is not available. -if not ipautil.file_exists(self.command): +if not self.command: raise AssertionError( -'Command %r not available' % self.command +'Command %r not available' % original_command ) super(cmdline_test, self).setUp() if not server_available: diff --git a/ipatests/test_cmdline/test_ipagetkeytab.py b/ipatests/test_cmdline/test_ipagetkeytab.py index cb46fd23bf320f59c30e53ceaa85d09aa7a3e2b4..ee2fdecf041c2af14c435db0f93493cd49a3999b 100644 --- a/ipatests/test_cmdline/test_ipagetkeytab.py +++ b/ipatests/test_cmdline/test_ipagetkeytab.py @@ -59,7 +59,7 @@ class test_ipagetkeytab(cmdline_test): Test `ipa-getkeytab`. -command = ipa-client/ipa-getkeytab +command = ipa-getkeytab host_fqdn = u'ipatest.%s' % api.env.domain service_princ = u'test/%s@%s' % (host_fqdn, api.env.realm) [keytabfd, keytabname] = tempfile.mkstemp() diff --git a/make-test b/make-test index 1cf5bb32975df76574726d5da4522517e5e12eed..2a48ab18181fe313b413b8c64f300533215380bc 100755 --- a/make-test +++ b/make-test @@ -29,6 +29,9 @@ cmd += sys.argv[1:] # This must be set so ipalib.api gets initialized property for tests: os.environ['IPA_UNIT_TEST_MODE'] =
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 5.3.2014 14:21, Simo Sorce wrote: On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Let me summarize what we have: We agree that = - PKCS#11 is the right interface for key manipulation and certificate retrieval. - We can have PKCS#11 client library talking to local SSSD so the data retrieval logic can be hidden in SSSD (something like PKCS-responder). Open questions/variants to
Re: [Freeipa-devel] LDAP schema for PKCS#11
In your descriptions, can you translate all acronyms according to: http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__5__SYMBOLS__AND__ABBREVIATIONS.html ...and... http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__2__COMMON__ATTRIBUTES.html E.g., instead of saying pkcs11certificateCategory is represent CKA_CERTIFICATE_CATEGORY, can you say, Categorization of the certificate: 0 = unspecified (default value), 1 = token user, 2 = authority, 3 = other entity or whatever the translation of that enumeration might be in LDAP. You have good descriptions throughout your spec, but don't put those descriptions into your rfc2252 LDAP attribute definitions where they belong. Also, how are you deciding on capitalization in all cases? E.g, pkcs11uniqueid vs. pkcs11uniqueId vs. pkcs11uniqueID. See #3.5, supposed to be pkcs11nsstrust (pkcs11nssTrust?), but it starts with ( ipapkcs11OID.2.5 NAME 'pkcs11certificate' . I guess the crux of my recommendation is: make your schema entirely independent of the PKCS#11 standard. In other words, incorporate more of the standard's language into your actual schema definition file, so that users don't have to constantly compare and contrast against separate documents. Removing or at least demoting PKCS#11 C library #define artifacts. Thanks, Derek On Mon, Mar 3, 2014 at 5:51 AM, Ludwig Krispenz lkris...@redhat.com wrote: Hi, starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema Here are some design decisions I made and which need to be finally decided. 1] Add nss trust objects. These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. 3] Key attributes Like certificates keys can be stored ina single attribute as pkcs8 or bind.key format. In pkcs11 the keys are defined by their algoritthm specific attributes, I had defined RSA specific attributes (moduleus, exponent, ) and did not remove them. Maybe some app wants to create keys and store these attrs, having defined them does not force to use them, but allows flexibility without requiring new attribute definitions 4] Not needed attributes. Jan pointed out that some of the attributes like CKA_TOKEN will always be true, so no need to define them. I have not yet removed them, they don't nned to be used, but I can still remove them. 5] Attribute syntaxes I associated boolean attributes with the ldap boolean syntax, which requires TRUE/FALSE as values There are a couple of attributes with a limited range like key_type which has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for these values which translate them to integers, which could be used, but I propose to use a syntax of directoryString and use the values directly eg pkcs11keyType: CKK_RSA. To me this is more readable than pkcs11keyType: 0 And it would have to be parsed anywy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/05/2014 03:04 PM, Simo Sorce wrote: On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Yeah, but the plan is not force people to have the heavy weight Java infrastructure on each server so that they are able to create more lightweight servers only with components they choose: https://fedorahosted.org/freeipa/ticket/4058 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0487 ipalib.plugable: Always set the parser in bootstrap()
On 5.3.2014 14:51, Petr Viktorin wrote: Hello, This patch fixes a failing test setup where logging was configured before the API was bootstrapped. The __setattr__ is moved before a conditional return. ACK, the test failures are gone. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Wed, 2014-03-05 at 16:29 +0100, Martin Kosek wrote: On 03/05/2014 03:04 PM, Simo Sorce wrote: On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Yeah, but the plan is not force people to have the heavy weight Java infrastructure on each server so that they are able to create more lightweight servers only with components they choose: https://fedorahosted.org/freeipa/ticket/4058 Yes, but the Vault does not need to be installed on each server, just on a couple of them like for the CA. In particular it doesn't need to be installed on the same servers that offer the DNS service. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0488 tests: Create the testing service certificate on demand
Hello,
This transforms the make-testcert command into a module that creates
the certificate when it is first needed.
As a result the tests are more self-contained, and can be run from
a read-only location (such as from the freeipa-tests package).
With 0235, 0487, and this patch, `ipa-run-tests` passes. (It logs too
much so it doesn't look pretty, but it passes.)
--
Petr³
From a82e4b40a8732f3e1a062c21e0cd587af563efc3 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 5 Mar 2014 16:46:21 +0100
Subject: [PATCH] tests: Create the testing service certificate on demand
Replace the make-testcert command with a module that creates
the certificate when it is first needed.
As a result the tests are more self-contained, and can be run from
a read-only location (such as installed from a system package).
---
.gitignore | 1 -
Makefile| 1 -
ipatests/test_xmlrpc/test_host_plugin.py| 22 ++---
ipatests/test_xmlrpc/test_service_plugin.py | 24 ++---
ipatests/test_xmlrpc/testcert.py| 103 +
make-testcert | 136
6 files changed, 121 insertions(+), 166 deletions(-)
create mode 100644 ipatests/test_xmlrpc/testcert.py
delete mode 100755 make-testcert
diff --git a/.gitignore b/.gitignore
index 6ff372b372d894dd2368018d151eca39d594b25e..04eb68371135d81468189e6b09c43dbe3e364834 100644
--- a/.gitignore
+++ b/.gitignore
@@ -64,7 +64,6 @@ freeipa2-dev-doc
/ipa-client/ipa-join
/ipa-client/ipa-rmkeytab
-/ipatests/test_xmlrpc/service.crt
/ipatests/setup.py
/ipapython/setup.py
diff --git a/Makefile b/Makefile
index af68e42b71ad12ff86cc5a0c8752e1246e565e7f..2808f6153c1920f66dc7729f9ae6ef8798cb0e19 100644
--- a/Makefile
+++ b/Makefile
@@ -113,7 +113,6 @@ lint: bootstrap-autogen
test:
- ./make-testcert
./make-test
release-update:
diff --git a/ipatests/test_xmlrpc/test_host_plugin.py b/ipatests/test_xmlrpc/test_host_plugin.py
index 300e1c25e47d76d92534577e591cda174dc4fed8..af42ee54dc1a35428f88a236279e1093b778c532 100644
--- a/ipatests/test_xmlrpc/test_host_plugin.py
+++ b/ipatests/test_xmlrpc/test_host_plugin.py
@@ -28,11 +28,12 @@
from ipalib import api, errors, x509
from ipapython.dn import DN
from nose.tools import raises, assert_raises
-from nose.plugins.skip import Skip, SkipTest
+from nose.plugins.skip import SkipTest
from ipatests.test_xmlrpc.xmlrpc_test import (Declarative, XMLRPC_test,
fuzzy_uuid, fuzzy_digits, fuzzy_hash, fuzzy_date, fuzzy_issuer,
fuzzy_hex)
from ipatests.test_xmlrpc import objectclasses
+from ipatests.test_xmlrpc.testcert import get_testcert
import base64
@@ -55,13 +56,6 @@
api.env.basedn)
invalidfqdn1 = u'foo_bar.lab.%s' % api.env.domain
-# We can use the same cert we generated for the service tests
-fd = open('ipatests/test_xmlrpc/service.crt', 'r')
-servercert = fd.readlines()
-servercert = ''.join(servercert)
-servercert = x509.strip_header(servercert)
-fd.close()
-
sshpubkey = u'ssh-rsa B3NzaC1yc2EDAQABAAABAQDGAX3xAeLeaJggwTqMjxNwa6XHBUAikXPGMzEpVrlLDCZtv00djsFTBi38PkgxBJVkgRWMrcBsr/35lq7P6w8KGIwA8GI48Z0qBS2NBMJ2u9WQ2hjLN6GdMlo77O0uJY3251p12pCVIS/bHRSq8kHO2No8g7KA9fGGcagPfQH+ee3t7HUkpbQkFTmbPPN++r3V8oVUk5LxbryB3UIIVzNmcSIn3JrXynlvui4MixvrtX6zx+O/bBo68o8/eZD26QrahVbA09fivrn/4h3TM019Eu/c2jOdckfU3cHUV/3Tno5d6JicibyaoDDK7S/yjdn5jhaz8MSEayQvFkZkiF0L public key test'
sshpubkeyfp = u'13:67:6B:BF:4E:A2:05:8E:AE:25:8B:A1:31:DE:6F:1B public key test (ssh-rsa)'
@@ -254,7 +248,7 @@ class test_host(Declarative):
dict(
desc='Update %r' % fqdn1,
command=('host_mod', [fqdn1], dict(description=u'Updated host 1',
-usercertificate=servercert)),
+usercertificate=get_testcert())),
expected=dict(
value=fqdn1,
summary=u'Modified host %s' % fqdn1,
@@ -264,7 +258,7 @@ class test_host(Declarative):
l=[u'Undisclosed location 1'],
krbprincipalname=[u'host/%s@%s' % (fqdn1, api.env.realm)],
managedby_host=[u'%s' % fqdn1],
-usercertificate=[base64.b64decode(servercert)],
+usercertificate=[base64.b64decode(get_testcert())],
valid_not_before=fuzzy_date,
valid_not_after=fuzzy_date,
subject=DN(('CN',api.env.host),x509.subject_base()),
@@ -295,7 +289,7 @@ class test_host(Declarative):
has_keytab=False,
has_password=False,
managedby_host=[u'%s' % fqdn1],
-usercertificate=[base64.b64decode(servercert)],
+usercertificate=[base64.b64decode(get_testcert())],
valid_not_before=fuzzy_date,
valid_not_after=fuzzy_date,
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 5.3.2014 16:02, Petr Spacek wrote: On 5.3.2014 14:21, Simo Sorce wrote: On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Let me summarize what we have: We agree that = - PKCS#11 is the right interface for key manipulation and certificate retrieval. - We can have PKCS#11 client library talking to local SSSD so the data retrieval logic can be hidden in SSSD (something like
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 5.3.2014 13:20, Stef Walter wrote: On 03.03.2014 15:24, Jan Cholasta wrote: On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? I obviously think that using the new stuff linked above would be best. It's future proof and models this comprehensively. That would allow extracting compat trust anchors to files (for crypto libraries that don't yet support looking it up trust via PKCS#11). But I understand if you're hesitant to commit to this spec that's in development (albeit already implemented). Actually, I like it. Is everything mentioned at http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html going to be standardized? There's a third simple way to store trust, which is using standard PKCS#11. It's very limited: * Store certificates with the CKA_TRUSTED attribute set to CKA_TRUE and CKA_CERTIFICATE_CATEGORY set to 2. This method covers storing certificate authority anchors only. The above spec is a superset of this simple way of storing trust. NSS trust objects are not. So I would suggest implementing this simple mechanism and then implement the full spec later. I'm afraid this is simple too much. If you want to have a call/hangout about this and discuss, I'd be happy to. Thanks! Cheers, Stef -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
