date:20140227

On 02/27/2014 05:46 PM, Rich Megginson wrote:
> On 02/27/2014 09:37 AM, Petr Spacek wrote:
>> On 27.2.2014 17:24, Ludwig Krispenz wrote:
>>>
>>> On 02/27/2014 03:56 PM, Jan Cholasta wrote:
 On 27.2.2014 15:23, Ludwig Krispenz wrote:
>
> On 02/27/2014 02:14 PM, Jan Cholasta wrote:
>> On 18.2.2014 17:19, Martin Kosek wrote:
>>> On 02/18/2014 04:38 PM, Jan Cholasta wrote:
 On 18.2.2014 16:35, Petr Spacek wrote:
> On 18.2.2014 16:31, Jan Cholasta wrote:
>
> 2] low level replacement for eg the sqlite3 database in softhsm.
> That's what I sometimes get the impression what is wanted.
> SoftHsm has
> one component Softdatabase with an API, which more or less
> passes sets
> of attributes (attributes defined by PKCS#11) and then stores
> it as
> records in sql where each record has a keytype and opaque blob of
> data.
> If that is what is wanted the decision would be how fingrained the
> pkcs
> objects/attribute types would have to be mapped to ldap: one ldap
> attribute for each possible attribute type ?

 One-to-one mapping of attributes from PKCS#11 to LDAP would be
 the most
 straightforward way of doing this, but I think we can do some
 optimization for our needs. For example, like you said above, we
 can
 use
 a single attribute containing PKCS#8 encoded private key rather
 than
 using one attribute per private key component.

 I don't think we need an LDAP attribute for every possible PKCS#11
 attribute, ATM it would be sufficient to have just these attributes
 necessary to represent private key, public key and certificate
 objects.

 So, I would say it should be something between high-level and
 low-level.
>>>
>>> There won't be a separate public key, it's represented by the
>>> certificate.
>>
>> I'm not sure if this is the case for DNSSEC.
>
> Honzo,
>
> we really need the design page with some goal statement, high-level
> overview etc. There is still some confusion, probably from fact
> that we
> want to use the same module for cert distribution and at the same time
> for DNSSEC key storage.
>

 It's on my TODO list, I'll try to get it out ASAP.

>>>
>>> +1, please do. We clearly need some design to start with.
>>>
>>> Martin
>>>
>>
>> I already posted the link in other thread, but here it is anyway:
>> .
>>
>> Some more comments on the schema:
>>
>> I think I may have been too quick to dismiss RFC 4523. There is
>> CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
>> user", "authority" and "other entity". We could map entries with
>> object class pkiUser to certificate object with
>> CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
>> pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority".
>> There are no object classes in RFC 4523 for "unspecified" and "other
>> entity", but we will not be storing any certificates using PKCS#11
>> anyway, so I think it's OK.
> not sure I understand what exactly you want here. If we don't store
> certificates using the pkcs#11 schema we don't need to define them, but
> on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
> Do you mean to have a pkcs11 cerificate object with
> CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
> userCertificate and cACertificate to store them ?

 Hopefully an example will better illustrate what I mean. We could map
 PKCS#11 objects like this:

 CKA_CLASS: CKO_CERTIFICATE
 CKA_CERTIFICATE_TYPE: CKC_X_509
 CKA_CERTIFICATE_CATEGORY: 1
 CKA_VALUE: 
 

 to LDAP entries like this:

 dn: pkcs11uniqueId=,
 objectClass: pkcs11storageObject
 objectClass: pkiUser
 pkcs11uniqueId: 
 userCertificate;binary: 
 

 and PKCS#11 object like this:

 CKA_CLASS: CKO_CERTIFICATE
 CKA_CERTIFICATE_TYPE: CKC_X_509
 CKA_CERTIFICATE_CATEGORY: 2
 CKA_VALUE: 
 

 to LDAP entries like this:

 dn: pkcs11uniqueId=,
 objectClass: pkcs11storageObject
 objectClass: pkiCA
 pkcs11uniqueId: 
 caCertificate;binary: 
 

 In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
 objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" and
>>>

Re: [Freeipa-devel] Client-side command in the IPA framework


Alexander Bokovoy wrote:

On Thu, 27 Feb 2014, Nathaniel McCallum wrote:

So the recent discussion on importing tokens led me to write a script to
parse RFC 6030 xml files into IPA token data. This all works well. But
now I need to integrate it into the IPA framework.

This command will parse one or more xml files, creating a set of tokens
to be added. Given that we already have otptoken-add on the server-side,
it seems to me that all work needs to be done on the client-side. How do
I create a new client-side command that calls existing server-side API?

subclass from frontend.Local, override run() or forward() method and
perform batch
operation of otptoken_add from there.

See cli.help, for example.


If you do an override, do forward() for cli-specific work.

But you should do as little as possible for reasons you already stated: 
the UI. Anything you do in forward Petr will need to implement in the UI.


Unfortunately we don't yet have a nice way to handle files. We have 
tickets open at https://fedorahosted.org/freeipa/ticket/1225 and 
https://fedorahosted.org/freeipa/ticket/2933


If this file is something that would be pasted into a big text field 
then you can probably handle it in a similarly clumsy way that we do 
CSRs in the cert plugin.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] How to restore an IPA Replica when the CSN number generator has moved impossibly far into the future or past


  
  
On 02/03/2014 10:37 PM, JR Aquino
  wrote:

If you are seeing clock skew errors in
  /var/log/dirsrv/slapd-EXAMPLE-COM/errors that look like this, then
  you will need to verify the time/date of the server to make sure
  NTP isn't freaked out. If the system date is correct, it is
  possible that the change number generator has skewed.


Thanks much JR!  I have wiki-fied this email
http://port389.org/wiki/Howto:Fix_and_Reset_Time_Skew

I would like to credit you on the page - how would you like to be
attributed?


  [01/Feb/2014:14:42:06 -0800] NSMMReplicationPlugin - conn=12949
  op=7 repl="dc=example,dc=com": Excessive clock skew from supplier
  RUV
  [01/Feb/2014:14:42:06 -0800] - csngen_adjust_time: adjustment
  limit exceeded; value - 1448518, limit - 86400
  [01/Feb/2014:14:42:06 -0800] - CSN generator's state:
  [01/Feb/2014:14:42:06 -0800] -  replica id: 115
  [01/Feb/2014:14:42:06 -0800] -  sampled time: 1391294526
  [01/Feb/2014:14:42:06 -0800] -  local offset: 0
  [01/Feb/2014:14:42:06 -0800] -  remote offset: 0
  [01/Feb/2014:14:42:06 -0800] -  sequence number: 55067
  
  The following NsState_Script should be used to determine whether
  the change number generator has jumped significantly from the real
  time/date.
  https://github.com/richm/scripts/blob/master/readNsState.py
  
  
  The usage for the script works like this:
  
  [r...@ipaserver.ops jaquino]# ./readNsState.py
  /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif
  nsState is
  cwBGPfBSAQACAA==
  Little Endian
  For replica cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
  tree,cn=config
    fmtstr=[H6x3QH6x]
    size=40
    len of nsstate is 40
    CSN generator state:
      Replica ID    : 115
      Sampled Time  : 1391476038
      Gen as csn    : 52f03d4600020115
      Time as str   : Mon Feb  3 17:07:18 2014
      Local Offset  : 0
      Remote Offset : 1
      Seq. num      : 2
      System time   : Mon Feb  3 17:09:11 2014
      Diff in sec.  : 113
      Day:sec diff  : 0:113
  
  If the output from the above command is over a day or more out of
  sync, then the reason is because the CSN generator has become
  grossly skewed. It will be necessary to perform the following
  steps to recover.
  
  
  How to resolve this issue

  • 1: Select an ipa server to be authoritative and write the
  contents of its database to an ldif file
     On the master supplier:
     /var/lib/dirsrv/scripts-EXAMPLE-COM/db2ldif.pl -D
  'cn=Directory Manager' -w - -n userRoot -a
  /tmp/master-389.ldif
     Note that without the -r option it is deliberately ommiting
  the tainted replication data which contains the bad CSNs
  
  • 2: On the ipa server, shutdown its dirsrv daemon down so
  that you can reset the attribute responsible for the serial
  generation, and so that you can re-initialize its db from the
  known good ldif
     On the master supplier:
     ipactl stop
    
  
  • 3: Sanitize the dse.ldif Configuration File
     On  the master supplier: 
     edit the /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file and
  remove the nsState attribute from the replica config entry
     You DO NOT want to remove the nsState from: dn: cn=uniqueid
  generator,cn=config
  
     The stanza you want to remove the value from is: dn:
  cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping
  tree,cn=config
     The attribute will look like this: nsState::
  cwA3QPBSAQABAA==
     Delete the entire line
  
  • 3.1: Remove traces of stale CSN tracking in the Replica
  Agreements themeselves
     File location: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif
     cat dse.ldif | sed -n '1 {h; $ !d}; $ {x; s/\n //g; p}; /^
  / {H; d}; /^ /! {x; s/\n //g; p}' | grep -v nsds50ruv >
  new.dse.ldif
     backup the old dse.ldif and replace it with the new one:
     # mv dse.ldif dse.saved.ldif
     # mv new.dse.ldif dse.ldif
  
  • 4: Import the data from the known good ldif. This will mark
  all the changes with CSNs that match the current time/date
  stamps
     On  the master supplier:
     chmod 644 /tmp/master-389.ldif
     /var/lib/dirsrv/scripts-EXAMPLE-COM/ldif2db -n userRoot -i
  /tmp/master-389.ldif
  
  • 5: Restart the ipa daemons on the master supplier
     #ipactl start

Re: [Freeipa-devel] Client-side command in the IPA framework


On Thu, 27 Feb 2014, Nathaniel McCallum wrote:

So the recent discussion on importing tokens led me to write a script to
parse RFC 6030 xml files into IPA token data. This all works well. But
now I need to integrate it into the IPA framework.

This command will parse one or more xml files, creating a set of tokens
to be added. Given that we already have otptoken-add on the server-side,
it seems to me that all work needs to be done on the client-side. How do
I create a new client-side command that calls existing server-side API?

subclass from frontend.Local, override run() or forward() method and perform 
batch
operation of otptoken_add from there.

See cli.help, for example.
--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Client-side command in the IPA framework

On Thu, 2014-02-27 at 17:44 -0500, Nathaniel McCallum wrote:
> So the recent discussion on importing tokens led me to write a script to
> parse RFC 6030 xml files into IPA token data. This all works well. But
> now I need to integrate it into the IPA framework.
> 
> This command will parse one or more xml files, creating a set of tokens
> to be added. Given that we already have otptoken-add on the server-side,
> it seems to me that all work needs to be done on the client-side. How do
> I create a new client-side command that calls existing server-side API?

Also, would it be better to send the whole file to the server and do the
parsing on the server side? Would this simplify UI implementation? Would
we run into trouble with large files?

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] Client-side command in the IPA framework

So the recent discussion on importing tokens led me to write a script to
parse RFC 6030 xml files into IPA token data. This all works well. But
now I need to integrate it into the IPA framework.

This command will parse one or more xml files, creating a set of tokens
to be added. Given that we already have otptoken-add on the server-side,
it seems to me that all work needs to be done on the client-side. How do
I create a new client-side command that calls existing server-side API?

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy

Rob Crittenden wrote:

Dmitri Pal wrote:

On 02/17/2014 04:57 PM, Rob Crittenden wrote:

Dmitri Pal wrote:

On 02/17/2014 04:13 PM, Rob Crittenden wrote:

Dmitri Pal wrote:

On 02/17/2014 02:33 PM, Rob Crittenden wrote:

Dmitri Pal wrote:

On 02/17/2014 01:21 PM, Rob Crittenden wrote:

Martin Kosek wrote:

On 02/14/2014 11:26 PM, Dmitri Pal wrote:
+1, this was exactly my goal. It is easy to name and organize
things
now,
difficult to do when it is live upstream and/or integrated with
Foreman.

I think the key for the right naming is a fact if this is really
specific to
Foreman or it is a truly general design usable also in other use
cases. If
Foreman-specific, I would go with
freeipa-server-smartproxy-host or
similar.

If general, we can go with

freeipa-server-proxy-host
freeipa-server-proxy-user
freeipa-server-proxy-dhcp

The proxies may share the framework and only expose the requested
part of the
tree - which in advance gives you an option for an API
separation, as
compared
to general freeipa-server-smartproxy.

I still don't get the point of this. Are you proposing having 3
different servers, each providing a unique service? Or one service
that one can turn on/off features, or something else? Do you
envision
this as 3 separate subpackages?

There is no "framework" in my current patch, it is a cherrypy
server
that exposes parts of IPA on a given URI. It is the thinnest of
layers.

Then it seems to make sense to have 3 different packages that
can be
optionally coninstalled and would probably share the same
principal,
keytab and local REST API socket/port.

Well, what you are designing is a central framework with plugins.
What
I designed is a quick-and-dirty get something up quickly. We need to
pick one. The plugable method is going to require a fair bit of
rework, though it will potentially pay dividends in the future.

I think that we can start where you are but drive towards this
architecture via refactoring. But we need to pick the right name now.
Even if the architecture is not there yet we should name the
package in
such way that it does not preclude us from moving towards a clean
architecture I described during the next iteration.

Just having a hard time seeing the value. This would be like making
each of the IPA plugins a separate package and somehow installing them
individually.

To do this you'd need at least 2 packages, a high level one with the
"framework" and then a separate one for each data type.

This could also be achieved, and likely more cleanly, without all
these extra packages, as a simple configuration file. Once a package,
always a package.

Maybe I'm too close to the problem, but to me this is a
Foreman-specific solution. The "smartproxy" is a Foreman creation, I
don't know that anything else is using it. If you want a RESTful
server, then we enable REST in IPA directly, but selectively enabling
and disabling APIs is not something we've done before. It has been
controlled by ACIs instead.

rob

We are trying to predict future here. Say we release it as you suggest.
Tomorrow we point someone upstream who wants to add users to IPA from a
similar proxy to this implementation and say use this as a model.
And then Rich needs the same but for DNS for Designate.

What would be the best? Rob if you knew that tomorrow two other
developers will create similar proxies for users and DNS would you
change anything? Would you provide some guidelines to them?
If you are close to the problem you should be able to at least tell
them: "copy and paste" vs. "add more APIs to the same proxy".
If your recommendation is copy and paste then I suspect there will be
challenges of running these proxies on the same machine - they will
collide on ports and sockets. If we say "extend" shouldn't we use a
more
generic name?

I'd say "use the existing IPA API". The only reason we have to write
the smartproxy at all is to interoperate with another service that
already has a well-defined remote server API which uses REST.

rob

OK, so you think that proxy is one off. OK I am fine with it.
I was under assumption that it would be a beginning of a trend but I
might be wrong as I do not have valid arguments to prove or disprove one
way or another.
I guess time would show.

Any objections to Rob's approach?

Ok, so try to summarize this long-running thread, I'll rename the
subpackage to freeipa-server-foreman-smartproxy to make it clearer what
it is/does. Right now it requires manual configuration so having the
package installed should have no negative impacts (other than
potentially pulling in additional dependencies).

I'll leave it in smartproxy for now, it's just cleaner and better
integrates with ipatests IMHO.

Foreman supports SSL client auth which is great, by cherrypy does not
yet. There is a pull request to add this,
https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity
. Foreman otherwise supports no other authentication method, so we're
blocked wit

Re: [Freeipa-devel] DNSSEC design page


On 02/27/2014 01:10 PM, Petr Spacek wrote:

On 27.2.2014 17:55, Ludwig Krispenz wrote:


On 02/27/2014 05:46 PM, Rich Megginson wrote:

On 02/27/2014 09:37 AM, Petr Spacek wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in 
softhsm.

That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then 
stores

it as
records in sql where each record has a keytype and 
opaque blob of

data.
If that is what is wanted the decision would be how 
fingrained the

pkcs
objects/attribute types would have to be mapped to ldap: 
one ldap

attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP 
would be

the most
straightforward way of doing this, but I think we can do 
some
optimization for our needs. For example, like you said 
above, we

can
use
a single attribute containing PKCS#8 encoded private key 
rather

than
using one attribute per private key component.

I don't think we need an LDAP attribute for every 
possible PKCS#11
attribute, ATM it would be sufficient to have just these 
attributes
necessary to represent private key, public key and 
certificate

objects.

So, I would say it should be something between high-level 
and

low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, 
high-level

overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the 
same time

for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", 
"token

user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object 
class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY 
"authority".
There are no object classes in RFC 4523 for "unspecified" and 
"other

entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define 
them, but
on the other hand you talk about the usage of 
CKA_CERTIFICATE_CATEGORY.

Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could 
map

PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied 
from
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: 
pkiUser" and

"CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".
so you want to directly use the pkiUser|CA objectclass, that would 
be ok




Also the above got me thinking, is there any "standard" LDAP 
schema

for private keys? If so, can we use it?
I didn't find any, the only keys in ldap I found is a definition 
for

sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA 
certificates, so
I'm going to need an object class for that. You can find the 
details

on CKO_NSS_TRUST at
. 




so this is a nss  extension to pkcs11, not in the standard ? If we 
add trust

objects, should the naming reflect this like pkcs11nss or
pkcs11ext ?



If we store multiple related PKCS#11 objects

Re: [Freeipa-devel] DNSSEC design page

2014-02-27 Thread Petr Spacek


On 27.2.2014 17:55, Ludwig Krispenz wrote:


On 02/27/2014 05:46 PM, Rich Megginson wrote:

On 02/27/2014 09:37 AM, Petr Spacek wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority".
There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" and
"CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".

so you want to directly use the pkiUser|CA objectclass, that would be ok




Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
.



so this is a nss  extension to pkcs11, not in the standard ? If we add trust
objects, should the naming reflect this like pkcs11nss or
pkcs11ext ?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 05:46 PM, Rich Megginson wrote:

On 02/27/2014 09:37 AM, Petr Spacek wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in 
softhsm.

That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque 
blob of

data.
If that is what is wanted the decision would be how 
fingrained the

pkcs
objects/attribute types would have to be mapped to ldap: 
one ldap

attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said 
above, we

can
use
a single attribute containing PKCS#8 encoded private key 
rather

than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible 
PKCS#11
attribute, ATM it would be sufficient to have just these 
attributes

necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, 
high-level

overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the 
same time

for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY 
"authority".

There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define 
them, but
on the other hand you talk about the usage of 
CKA_CERTIFICATE_CATEGORY.

Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: 
pkiUser" and

"CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".
so you want to directly use the pkiUser|CA objectclass, that would 
be ok




Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
. 



so this is a nss  extension to pkcs11, not in the standard ? If we 
add trust
objects, should the naming reflect this like pkcs11nss or 
pkcs11ext ?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be extracted f

Re: [Freeipa-devel] DNSSEC design page


On 27.2.2014 17:49, Ludwig Krispenz wrote:


On 02/27/2014 05:48 PM, Jan Cholasta wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in
softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque
blob of
data.
If that is what is wanted the decision would be how
fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one
ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said
above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible
PKCS#11
attribute, ATM it would be sufficient to have just these
attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement,
high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same
time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY
"authority".
There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them,
but
on the other hand you talk about the usage of
CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser"
and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".

so you want to directly use the pkiUser|CA objectclass, that would be ok


I think it would make sense after all, if that's OK by the present
LDAP gurus :-)





Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
.



so this is a nss  extension to pkcs11, not in the standard ? If we add
trust objects, should the naming reflect this like pkcs11nss or
pkcs11ext ?


Yes, it's a NSS vendor-specific extension. I like the prefix "pkcs11nss".




If we store multiple rel

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 05:48 PM, Jan Cholasta wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in 
softhsm.

That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque
blob of
data.
If that is what is wanted the decision would be how
fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one
ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said 
above, we

can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible
PKCS#11
attribute, ATM it would be sufficient to have just these
attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, 
high-level

overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same
time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY 
"authority".

There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, 
but
on the other hand you talk about the usage of 
CKA_CERTIFICATE_CATEGORY.

Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser"
and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".

so you want to directly use the pkiUser|CA objectclass, that would be ok


I think it would make sense after all, if that's OK by the present 
LDAP gurus :-)






Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
. 




so this is a nss  extension to pkcs11, not in the standard ? If we add
trust objects, should the naming reflect this like pkcs11nss or
pkcs11ext ?


Yes, it's a NSS vendor-specific extension. I like the prefix "pkcs11nss".




If we store multiple related PKCS#11 objects in a sin

Re: [Freeipa-devel] DNSSEC design page


On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque
blob of
data.
If that is what is wanted the decision would be how
fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one
ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible
PKCS#11
attribute, ATM it would be sufficient to have just these
attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same
time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority".
There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser"
and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".

so you want to directly use the pkiUser|CA objectclass, that would be ok


I think it would make sense after all, if that's OK by the present LDAP 
gurus :-)






Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
.


so this is a nss  extension to pkcs11, not in the standard ? If we add
trust objects, should the naming reflect this like pkcs11nss or
pkcs11ext ?


Yes, it's a NSS vendor-specific extension. I like the prefix "pkcs11nss".




If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For ex

Re: [Freeipa-devel] DNSSEC design page


On 02/27/2014 09:37 AM, Petr Spacek wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in 
softhsm.

That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque 
blob of

data.
If that is what is wanted the decision would be how 
fingrained the

pkcs
objects/attribute types would have to be mapped to ldap: 
one ldap

attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said 
above, we

can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible 
PKCS#11
attribute, ATM it would be sufficient to have just these 
attributes

necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, 
high-level

overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the 
same time

for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY 
"authority".

There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, 
but
on the other hand you talk about the usage of 
CKA_CERTIFICATE_CATEGORY.

Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: 
pkiUser" and

"CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".

so you want to directly use the pkiUser|CA objectclass, that would be ok




Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
. 



so this is a nss  extension to pkcs11, not in the standard ? If we 
add trust
objects, should the naming reflect this like pkcs11nss or 
pkcs11ext ?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be extracted from private key value, so we don't need to store
b

Re: [Freeipa-devel] [PATCH] 531-541 OTP UI

On Thu, 2014-02-27 at 17:29 +0100, Petr Vobornik wrote:
> On 27.2.2014 16:51, Nathaniel McCallum wrote:
> > On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote:
> >> On 21.2.2014 15:24, Petr Vobornik wrote:
> >>> On 10.2.2014 14:12, Petr Vobornik wrote:
>  On 13.1.2014 17:09, Petr Vobornik wrote:
> > Hi,
> >
> > these patches implements the OTP Web UI.
> >
> > Last 5 patches is the OTP UI.
> >
> > First 6 patches is a little refactoring/bug fixes needed for them.
> > General password dialog is introduced to avoid another implementation.
> >
> > Self-service UI is implemented to be very simple. Atm user can choose
> > only token name. Admin interface allows to enter all values.
> >
> > It's based on the RCUE work -> we need to push RCUE first. Thanks
> > Nathaniel for review of the last font package. It will speed things up.
> >
> > Know bugs:
> > - there is clash in id's of checkboxes preventing editation of
> > subsequently displayed ones with the same name. Will be fixed in
> > separate patch.
> > - bugs caused by bugs in API (adding/removal of own tokens in
> > self-service, inability to enter key on token creation -
> > https://fedorahosted.org/freeipa/ticket/4099)
> > - datetime format (widget+validator) will be implemented in separate
> > patch
> > - no support of not reviewed CLI patches (HOTP..)
> >
> > Cgit:
> > http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp
> >
> > https://fedorahosted.org/freeipa/ticket/3369
> >
> 
>  patch 540-1 has been updated
>  - QR code is centered
>  - QR code correction level was lowered from H to M
> 
>  All other current patches from sub-threads are attached as well (it was
>  getting hard to keep track of them).
> 
> >>>
> >>> Attaching new version of patch 537: 537-4
> >>>
> >>> It:
> >>> * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter
> >>> field in details facet
> >>> * removes 'default' radio button in adder dialog in ipatokenotpalgorithm
> >>> and ipatokenotpdigits field
> >>>
> >>>
> >>> Btw I've encountered an issue on Web UI login when:
> >>> - user is created
> >>> - token is created for him
> >>> - admin resets user's password and changes auth type to 'otp'
> >>> - user tries to login with psw+otp
> >>>
> >>> The initial login-password call is successful but subsequent change
> >>> password fails - it uses the old psw+otp.
> >>>
> >>> I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903
> >>> which is almost implemented.
> >>>
> >>>
> >>> I also plan to hide fields without any value in otp token details page
> >>> in self-service mode. This will be done after #3903 because some
> >>> prerequisites for #3903 add useful code for that task.
> >>>
> >>
> >> New version of 537 attached: 537-5
> >>
> >> It removes token type switch from selfservice page. Therefore default
> >> token type (totp) will be always created.
> >>
> >> Originated from:
> >> http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html
> >
> > I'm not sure I understand the rationale for this (after having read the
> > other email thread). But I agree we should discuss which options should
> > be available on the self-service page.
> >
> > Just to recap the situation:
> > 1. Only token name / description are provided in the self-service UI
> > 2. All options are provided on the CLI
> >
> > I think the main question is: who should get to choose the primary token
> > type in FreeIPA? There are three possibilities:
> > 1. FreeIPA developers
> > 2. Admins
> > 3. Users
> >
> > The case for #1 is that we can't guarantee timely replication of the
> > counter attribute. On this basis, we choose TOTP as default because of
> > structural limitations. This is currently the default.
> >
> > I don't see much use for #3. But I can see an argument for #2.
> >
> > Personally, I lean toward #1. Thoughts?
> >
> > Nathaniel
> >
> 
> Sorry, there is no real reason to not have HOTP there, and therefore 
> 537-5 is wrong and 537-4 is OK.
> 
> Rationale of the mistake:
> * self-service page has to be simple so it doesn't allow to add hw tokens
> * My thoughts were fixed to the idea that HOTP has to be hw token - 
> maybe the H confused me.

On a similar note, I've been toying with the idea of a
ipatokenRestricted attribute. The idea is that restricted tokens cannot
be created or deleted by users and, when the user is deleted, the token
is orphaned in stead of deleted. During XML import, the restricted
attribute would be set by default.

This seems to me the correct behavior.

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC design page

2014-02-27 Thread Petr Spacek


On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority".
There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" and
"CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".

so you want to directly use the pkiUser|CA objectclass, that would be ok




Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
.


so this is a nss  extension to pkcs11, not in the standard ? If we add trust
objects, should the naming reflect this like pkcs11nss or pkcs11ext 
?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be extracted from private key value, so we don't need to store
both of the values. This can be bypassed by having separate object
class

Re: [Freeipa-devel] [389-devel] Design review (second): Access control on entries specified in MODDN operation (ticket 47553)


Hi,

in the replication section you describe the behaviour when replicating 
to older versions of ds, but this is for n1, how about the new design ?


Ludwig
On 02/27/2014 04:46 PM, thierry bordaz wrote:

Hello,

Thanks to all your feedbacks, they helped me a lot and raised a severe 
limitation in the original design.
I updated the design following the aci syntax proposed during the 
discussion.
On the implementation side, it is a bit more complex but less than I 
expected. I have not yet investigated the impact of ger operations.


I think a big work will be the test side as the ACI syntax provides 
many options.


http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation

Note: I kept for the moment the original design in 'alternative no1'.

regards
thierry


___
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] Is there RPC documentation?

2014-02-27 Thread Simo Sorce

On Thu, 2014-02-27 at 08:41 -0700, Rich Megginson wrote:
> On 02/27/2014 06:19 AM, Rob Crittenden wrote:
> > Rich Megginson wrote:
> >> On 02/26/2014 03:48 PM, Simo Sorce wrote:
> >>> On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:
>  On 02/26/2014 03:22 PM, Rob Crittenden wrote:
> > Rich Megginson wrote:
> >> On 02/26/2014 02:19 PM, Rob Crittenden wrote:
> >>> Rich Megginson wrote:
>  On 02/26/2014 08:53 AM, Petr Viktorin wrote:
> > On 02/26/2014 04:45 PM, Rich Megginson wrote:
> >> I'm working on adding support for freeipa DNS to openstack
> >> designate
> >> (DNSaaS).  I am assuming I need to use RPC (XML?  JSON? 
> >> REST?) to
> >> communicate with freeipa.  Is there documentation about how to
> >> construct
> >> and send RPC messages?
> > The JSON-RPC and XML-RPC API is still not "officially supported"
> > (read: documented), though it's extremely unlikely to change.
> > If you need an example, run any ipa command with -vv, this will
> > print
> > out the request & response.
> > API.txt in the source tree lists all the commands and params.
> > This blog post still applies (but be sure to read the update 
> > about
> > --cacert):
> > http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
> >  
> >
> >
> >
> >
> >
> >
>  Ok.  Next question is - how does one do the equivalent of the curl
>  command in python code?
> >>> Here is a pretty stripped-down way to add a user. Other commands 
> >>> are
> >>> similar, you just may care more about the output:
> >>>
> >>> from ipalib import api
> >>> from ipalib import errors
> >>>
> >>> api.bootstrap(context='cli')
> >>> api.finalize()
> >>> api.Backend.xmlclient.connect()
> >>>
> >>> try:
> >>>  api.Command['user_add'](u'testuser',
> >>>  givenname=u'Test', sn=u'User',
> >>>  loginshell=u'/bin/sh')
> >>> except errors.DuplicateEntry:
> >>>  print "user already exists"
> >>> else:
> >>>  print "User added"
> >>>
> >> How would one do this from outside of ipa?  If ipalib is not
> >> available?
> > You'd need to go to either /ipa/xml or /ipa/json (depending on what
> > protocol you want to use) and issue one request there. This requires
> > Kerberos authentication. The response will include a cookie which you
> > should either ignore or store safely (like in the kernel keyring).
> > Using the cookie will significantly improve performance.
>  This is for the ipa dns backend for designate.  I'm assuming I will
>  either be using a keytab, or perhaps the new proxy?
> 
>  At any rate, I have to do everything in python - including the kinit
>  with the keytab.
> >>> Lok at rob's damon but you should *not* do a kinit, you should just use
> >>> gssapi (see python-kerberos) and do a gss_init_sec_context there, if 
> >>> the
> >>> environment is configured (KRB5_KTNAME set correctly) then gssapi will
> >>> automatically kinit for you under the hood.
> >>>
>  I guess I'm really looking for specifics - I've seen 
>  recommendations to
>  use the python libraries "requests" and "json".  I don't know if
>  requests supports negotiate/kerberos.  If not, is there a recommended
>  library to use?  As this particular project will be part of openstack,
>  perhaps there is a more "openstack"-y library, or even something
>  built-in to openstack (oslo?).  I think amqp support kerberos, so
>  perhaps there is some oslo.messaging thing that will do the http +
>  kerberos stuff.
> >>> Afaik there is nothing that does kerberos in openstack, you'll have to
> >>> introduce all that stuff.
> >>
> >> Egads - implementing openstack-wide kerberos client libraries in order
> >> to add an ipa dns backend to designate.
> >>
> >> Rob, need any help with your proxy?
> >
> > Well, something occurred to me this morning. You need SSL on top of 
> > this too, which means you need the IPA CA. The easiest way to get that 
> > is to enroll the designate server as an IPA client. This pulls in the 
> > freeipa-python package which gives you ipalib, so no reinventing the 
> > wheel required.
> 
> I'm trying to use python-kerberos to do auth with a keytab 
> (KRB5_KTNAME), without first doing a kinit from the command line. It is 
> not working.
> 
> Does anyone know how I can do client side kerberos auth with a keytab in 
> python without first doing a kinit?

Ping me privately if you can't make it work and we'll try to debug why.

Simo

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/

Re: [Freeipa-devel] Is there RPC documentation?

2014-02-27 Thread Simo Sorce

On Thu, 2014-02-27 at 11:32 -0500, Rob Crittenden wrote:
> Rich Megginson wrote:
> > On 02/27/2014 06:19 AM, Rob Crittenden wrote:
> >> Rich Megginson wrote:
> >>> On 02/26/2014 03:48 PM, Simo Sorce wrote:
>  On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:
> > On 02/26/2014 03:22 PM, Rob Crittenden wrote:
> >> Rich Megginson wrote:
> >>> On 02/26/2014 02:19 PM, Rob Crittenden wrote:
>  Rich Megginson wrote:
> > On 02/26/2014 08:53 AM, Petr Viktorin wrote:
> >> On 02/26/2014 04:45 PM, Rich Megginson wrote:
> >>> I'm working on adding support for freeipa DNS to openstack
> >>> designate
> >>> (DNSaaS).  I am assuming I need to use RPC (XML?  JSON?
> >>> REST?) to
> >>> communicate with freeipa.  Is there documentation about how to
> >>> construct
> >>> and send RPC messages?
> >> The JSON-RPC and XML-RPC API is still not "officially supported"
> >> (read: documented), though it's extremely unlikely to change.
> >> If you need an example, run any ipa command with -vv, this will
> >> print
> >> out the request & response.
> >> API.txt in the source tree lists all the commands and params.
> >> This blog post still applies (but be sure to read the update
> >> about
> >> --cacert):
> >> http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
> >>
> >>
> >>
> >>
> >>
> >>
> > Ok.  Next question is - how does one do the equivalent of the curl
> > command in python code?
>  Here is a pretty stripped-down way to add a user. Other commands
>  are
>  similar, you just may care more about the output:
> 
>  from ipalib import api
>  from ipalib import errors
> 
>  api.bootstrap(context='cli')
>  api.finalize()
>  api.Backend.xmlclient.connect()
> 
>  try:
>   api.Command['user_add'](u'testuser',
>   givenname=u'Test', sn=u'User',
>   loginshell=u'/bin/sh')
>  except errors.DuplicateEntry:
>   print "user already exists"
>  else:
>   print "User added"
> 
> >>> How would one do this from outside of ipa?  If ipalib is not
> >>> available?
> >> You'd need to go to either /ipa/xml or /ipa/json (depending on what
> >> protocol you want to use) and issue one request there. This requires
> >> Kerberos authentication. The response will include a cookie which you
> >> should either ignore or store safely (like in the kernel keyring).
> >> Using the cookie will significantly improve performance.
> > This is for the ipa dns backend for designate.  I'm assuming I will
> > either be using a keytab, or perhaps the new proxy?
> >
> > At any rate, I have to do everything in python - including the kinit
> > with the keytab.
>  Lok at rob's damon but you should *not* do a kinit, you should just use
>  gssapi (see python-kerberos) and do a gss_init_sec_context there, if
>  the
>  environment is configured (KRB5_KTNAME set correctly) then gssapi will
>  automatically kinit for you under the hood.
> 
> > I guess I'm really looking for specifics - I've seen
> > recommendations to
> > use the python libraries "requests" and "json".  I don't know if
> > requests supports negotiate/kerberos.  If not, is there a recommended
> > library to use?  As this particular project will be part of openstack,
> > perhaps there is a more "openstack"-y library, or even something
> > built-in to openstack (oslo?).  I think amqp support kerberos, so
> > perhaps there is some oslo.messaging thing that will do the http +
> > kerberos stuff.
>  Afaik there is nothing that does kerberos in openstack, you'll have to
>  introduce all that stuff.
> >>>
> >>> Egads - implementing openstack-wide kerberos client libraries in order
> >>> to add an ipa dns backend to designate.
> >>>
> >>> Rob, need any help with your proxy?
> >>
> >> Well, something occurred to me this morning. You need SSL on top of
> >> this too, which means you need the IPA CA. The easiest way to get that
> >> is to enroll the designate server as an IPA client. This pulls in the
> >> freeipa-python package which gives you ipalib, so no reinventing the
> >> wheel required.
> >
> > I'm trying to use python-kerberos to do auth with a keytab
> > (KRB5_KTNAME), without first doing a kinit from the command line. It is
> > not working.
> >
> > Does anyone know how I can do client side kerberos auth with a keytab in
> > python without first doing a kinit?
> 
> gssproxy. You need at least 0.3.1.
> 
> Add something like this to the _top_ of /etc/gssproxy/gssproxy.conf:
> 
> [service/myservice]
>  mechs = kr

Re: [Freeipa-devel] Is there RPC documentation?


Rich Megginson wrote:

On 02/27/2014 06:19 AM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 03:48 PM, Simo Sorce wrote:

On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:

On 02/26/2014 03:22 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack
designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON?
REST?) to
communicate with freeipa.  Is there documentation about how to
construct
and send RPC messages?

The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will
print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update
about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/







Ok.  Next question is - how does one do the equivalent of the curl
command in python code?

Here is a pretty stripped-down way to add a user. Other commands
are
similar, you just may care more about the output:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
 api.Command['user_add'](u'testuser',
 givenname=u'Test', sn=u'User',
 loginshell=u'/bin/sh')
except errors.DuplicateEntry:
 print "user already exists"
else:
 print "User added"


How would one do this from outside of ipa?  If ipalib is not
available?

You'd need to go to either /ipa/xml or /ipa/json (depending on what
protocol you want to use) and issue one request there. This requires
Kerberos authentication. The response will include a cookie which you
should either ignore or store safely (like in the kernel keyring).
Using the cookie will significantly improve performance.

This is for the ipa dns backend for designate.  I'm assuming I will
either be using a keytab, or perhaps the new proxy?

At any rate, I have to do everything in python - including the kinit
with the keytab.

Lok at rob's damon but you should *not* do a kinit, you should just use
gssapi (see python-kerberos) and do a gss_init_sec_context there, if
the
environment is configured (KRB5_KTNAME set correctly) then gssapi will
automatically kinit for you under the hood.


I guess I'm really looking for specifics - I've seen
recommendations to
use the python libraries "requests" and "json".  I don't know if
requests supports negotiate/kerberos.  If not, is there a recommended
library to use?  As this particular project will be part of openstack,
perhaps there is a more "openstack"-y library, or even something
built-in to openstack (oslo?).  I think amqp support kerberos, so
perhaps there is some oslo.messaging thing that will do the http +
kerberos stuff.

Afaik there is nothing that does kerberos in openstack, you'll have to
introduce all that stuff.


Egads - implementing openstack-wide kerberos client libraries in order
to add an ipa dns backend to designate.

Rob, need any help with your proxy?


Well, something occurred to me this morning. You need SSL on top of
this too, which means you need the IPA CA. The easiest way to get that
is to enroll the designate server as an IPA client. This pulls in the
freeipa-python package which gives you ipalib, so no reinventing the
wheel required.


I'm trying to use python-kerberos to do auth with a keytab
(KRB5_KTNAME), without first doing a kinit from the command line. It is
not working.

Does anyone know how I can do client side kerberos auth with a keytab in
python without first doing a kinit?


gssproxy. You need at least 0.3.1.

Add something like this to the _top_ of /etc/gssproxy/gssproxy.conf:

[service/myservice]
mechs = krb5
cred_store = client_keytab:/etc/my.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
cred_usage = initiate
euid = xx (where xx is the uid of your process)

I found running gssproxy directly in debug mode another window to be a 
handy debugging tool while I got my head wrapped around things.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 531-541 OTP UI

2014-02-27 Thread Petr Vobornik


On 27.2.2014 16:51, Nathaniel McCallum wrote:

On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote:

On 21.2.2014 15:24, Petr Vobornik wrote:

On 10.2.2014 14:12, Petr Vobornik wrote:

On 13.1.2014 17:09, Petr Vobornik wrote:

Hi,

these patches implements the OTP Web UI.

Last 5 patches is the OTP UI.

First 6 patches is a little refactoring/bug fixes needed for them.
General password dialog is introduced to avoid another implementation.

Self-service UI is implemented to be very simple. Atm user can choose
only token name. Admin interface allows to enter all values.

It's based on the RCUE work -> we need to push RCUE first. Thanks
Nathaniel for review of the last font package. It will speed things up.

Know bugs:
- there is clash in id's of checkboxes preventing editation of
subsequently displayed ones with the same name. Will be fixed in
separate patch.
- bugs caused by bugs in API (adding/removal of own tokens in
self-service, inability to enter key on token creation -
https://fedorahosted.org/freeipa/ticket/4099)
- datetime format (widget+validator) will be implemented in separate
patch
- no support of not reviewed CLI patches (HOTP..)

Cgit:
http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp

https://fedorahosted.org/freeipa/ticket/3369



patch 540-1 has been updated
- QR code is centered
- QR code correction level was lowered from H to M

All other current patches from sub-threads are attached as well (it was
getting hard to keep track of them).



Attaching new version of patch 537: 537-4

It:
* adds HOTP support - new switch in adder dialog and ipatokenhotpcounter
field in details facet
* removes 'default' radio button in adder dialog in ipatokenotpalgorithm
and ipatokenotpdigits field


Btw I've encountered an issue on Web UI login when:
- user is created
- token is created for him
- admin resets user's password and changes auth type to 'otp'
- user tries to login with psw+otp

The initial login-password call is successful but subsequent change
password fails - it uses the old psw+otp.

I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903
which is almost implemented.


I also plan to hide fields without any value in otp token details page
in self-service mode. This will be done after #3903 because some
prerequisites for #3903 add useful code for that task.



New version of 537 attached: 537-5

It removes token type switch from selfservice page. Therefore default
token type (totp) will be always created.

Originated from:
http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html


I'm not sure I understand the rationale for this (after having read the
other email thread). But I agree we should discuss which options should
be available on the self-service page.

Just to recap the situation:
1. Only token name / description are provided in the self-service UI
2. All options are provided on the CLI

I think the main question is: who should get to choose the primary token
type in FreeIPA? There are three possibilities:
1. FreeIPA developers
2. Admins
3. Users

The case for #1 is that we can't guarantee timely replication of the
counter attribute. On this basis, we choose TOTP as default because of
structural limitations. This is currently the default.

I don't see much use for #3. But I can see an argument for #2.

Personally, I lean toward #1. Thoughts?

Nathaniel



Sorry, there is no real reason to not have HOTP there, and therefore 
537-5 is wrong and 537-4 is OK.


Rationale of the mistake:
* self-service page has to be simple so it doesn't allow to add hw tokens
* My thoughts were fixed to the idea that HOTP has to be hw token - 
maybe the H confused me.

--
Petr Vobornik

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque 
blob of

data.
If that is what is wanted the decision would be how 
fingrained the

pkcs
objects/attribute types would have to be mapped to ldap: one 
ldap

attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible 
PKCS#11
attribute, ATM it would be sufficient to have just these 
attributes

necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same 
time

for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority".
There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map 
PKCS#11 objects like this:


CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from 
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" 
and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".

so you want to directly use the pkiUser|CA objectclass, that would be ok




Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
. 

so this is a nss  extension to pkcs11, not in the standard ? If we add 
trust objects, should the naming reflect this like pkcs11nss or 
pkcs11ext ?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be extracted from private key value, so we don't need to store
both of the values. This can be bypassed by having separate object
classes for data and for metadata

[Freeipa-devel] [389-devel] Design review (second): Access control on entries specified in MODDN operation (ticket 47553)

2014-02-27 Thread thierry bordaz


Hello,

Thanks to all your feedbacks, they helped me a lot and raised a severe 
limitation in the original design.
I updated the design following the aci syntax proposed during the 
discussion.
On the implementation side, it is a bit more complex but less than I 
expected. I have not yet investigated the impact of ger operations.


I think a big work will be the test side as the ACI syntax provides many 
options.


http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation

Note: I kept for the moment the original design in 'alternative no1'.

regards
thierry
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 531-541 OTP UI

On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote:
> On 21.2.2014 15:24, Petr Vobornik wrote:
> > On 10.2.2014 14:12, Petr Vobornik wrote:
> >> On 13.1.2014 17:09, Petr Vobornik wrote:
> >>> Hi,
> >>>
> >>> these patches implements the OTP Web UI.
> >>>
> >>> Last 5 patches is the OTP UI.
> >>>
> >>> First 6 patches is a little refactoring/bug fixes needed for them.
> >>> General password dialog is introduced to avoid another implementation.
> >>>
> >>> Self-service UI is implemented to be very simple. Atm user can choose
> >>> only token name. Admin interface allows to enter all values.
> >>>
> >>> It's based on the RCUE work -> we need to push RCUE first. Thanks
> >>> Nathaniel for review of the last font package. It will speed things up.
> >>>
> >>> Know bugs:
> >>> - there is clash in id's of checkboxes preventing editation of
> >>> subsequently displayed ones with the same name. Will be fixed in
> >>> separate patch.
> >>> - bugs caused by bugs in API (adding/removal of own tokens in
> >>> self-service, inability to enter key on token creation -
> >>> https://fedorahosted.org/freeipa/ticket/4099)
> >>> - datetime format (widget+validator) will be implemented in separate
> >>> patch
> >>> - no support of not reviewed CLI patches (HOTP..)
> >>>
> >>> Cgit:
> >>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/3369
> >>>
> >>
> >> patch 540-1 has been updated
> >> - QR code is centered
> >> - QR code correction level was lowered from H to M
> >>
> >> All other current patches from sub-threads are attached as well (it was
> >> getting hard to keep track of them).
> >>
> >
> > Attaching new version of patch 537: 537-4
> >
> > It:
> > * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter
> > field in details facet
> > * removes 'default' radio button in adder dialog in ipatokenotpalgorithm
> > and ipatokenotpdigits field
> >
> >
> > Btw I've encountered an issue on Web UI login when:
> > - user is created
> > - token is created for him
> > - admin resets user's password and changes auth type to 'otp'
> > - user tries to login with psw+otp
> >
> > The initial login-password call is successful but subsequent change
> > password fails - it uses the old psw+otp.
> >
> > I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903
> > which is almost implemented.
> >
> >
> > I also plan to hide fields without any value in otp token details page
> > in self-service mode. This will be done after #3903 because some
> > prerequisites for #3903 add useful code for that task.
> >
> 
> New version of 537 attached: 537-5
> 
> It removes token type switch from selfservice page. Therefore default 
> token type (totp) will be always created.
> 
> Originated from: 
> http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html

I'm not sure I understand the rationale for this (after having read the
other email thread). But I agree we should discuss which options should
be available on the self-service page.

Just to recap the situation:
1. Only token name / description are provided in the self-service UI
2. All options are provided on the CLI

I think the main question is: who should get to choose the primary token
type in FreeIPA? There are three possibilities:
1. FreeIPA developers
2. Admins
3. Users

The case for #1 is that we can't guarantee timely replication of the
counter attribute. On this basis, we choose TOTP as default because of
structural limitations. This is currently the default.

I don't see much use for #3. But I can see an argument for #2.

Personally, I lean toward #1. Thoughts?

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Is there RPC documentation?


On 02/27/2014 06:19 AM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 03:48 PM, Simo Sorce wrote:

On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:

On 02/26/2014 03:22 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack
designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? 
REST?) to

communicate with freeipa.  Is there documentation about how to
construct
and send RPC messages?

The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will
print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update 
about

--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ 








Ok.  Next question is - how does one do the equivalent of the curl
command in python code?
Here is a pretty stripped-down way to add a user. Other commands 
are

similar, you just may care more about the output:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
 api.Command['user_add'](u'testuser',
 givenname=u'Test', sn=u'User',
 loginshell=u'/bin/sh')
except errors.DuplicateEntry:
 print "user already exists"
else:
 print "User added"


How would one do this from outside of ipa?  If ipalib is not
available?

You'd need to go to either /ipa/xml or /ipa/json (depending on what
protocol you want to use) and issue one request there. This requires
Kerberos authentication. The response will include a cookie which you
should either ignore or store safely (like in the kernel keyring).
Using the cookie will significantly improve performance.

This is for the ipa dns backend for designate.  I'm assuming I will
either be using a keytab, or perhaps the new proxy?

At any rate, I have to do everything in python - including the kinit
with the keytab.

Lok at rob's damon but you should *not* do a kinit, you should just use
gssapi (see python-kerberos) and do a gss_init_sec_context there, if 
the

environment is configured (KRB5_KTNAME set correctly) then gssapi will
automatically kinit for you under the hood.

I guess I'm really looking for specifics - I've seen 
recommendations to

use the python libraries "requests" and "json".  I don't know if
requests supports negotiate/kerberos.  If not, is there a recommended
library to use?  As this particular project will be part of openstack,
perhaps there is a more "openstack"-y library, or even something
built-in to openstack (oslo?).  I think amqp support kerberos, so
perhaps there is some oslo.messaging thing that will do the http +
kerberos stuff.

Afaik there is nothing that does kerberos in openstack, you'll have to
introduce all that stuff.


Egads - implementing openstack-wide kerberos client libraries in order
to add an ipa dns backend to designate.

Rob, need any help with your proxy?


Well, something occurred to me this morning. You need SSL on top of 
this too, which means you need the IPA CA. The easiest way to get that 
is to enroll the designate server as an IPA client. This pulls in the 
freeipa-python package which gives you ipalib, so no reinventing the 
wheel required.


I'm trying to use python-kerberos to do auth with a keytab 
(KRB5_KTNAME), without first doing a kinit from the command line. It is 
not working.


Does anyone know how I can do client side kerberos auth with a keytab in 
python without first doing a kinit?




rob


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Thank you for FreeOTP!

On Tue, 2014-02-25 at 23:03 +0530, Kashyap Chamarthy wrote:
> Heya,
> 
> Just wanted to say thank you for FreeOTP, Nathaniel and co.
> 
> And, of course, more thankful to all the Identity open source/free
> software from this awesome team!
> 
> A happy user.

Kashyap,

Glad you like it! Thanks for the feedback.

Nathaniel


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC design page


On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority".
There are no object classes in RFC 4523 for "unspecified" and "other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map 
PKCS#11 objects like this:


CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: 
userCertificate;binary: 


and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: 


to LDAP entries like this:

dn: pkcs11uniqueId=,
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: 
caCertificate;binary: 


In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from 
objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=> "objectClass: pkiUser" 
and "CKA_CERTIFICATE_CATEGORY: 2" <=> "objectClass: pkiCA".




Also the above got me thinking, is there any "standard" LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
.


If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be extracted from private key value, so we don't need to store
both of the values. This can be bypassed by having separate object
classes for data and for metadata. For a key pair entry, the object
classes would be e.g. privateKey, pkcs11privateKey and
pkcs11publicKey, where privateKey is an object class with private key
data (without any PKCS#11 bits), pkcs11privateKey is an object class
with PKCS#11 private key metadata and pkcs11publicKey

Re: [Freeipa-devel] Thank you for FreeOTP!

2014-02-27 Thread Simo Sorce

On Tue, 2014-02-25 at 23:03 +0530, Kashyap Chamarthy wrote:
> Heya,
> 
> Just wanted to say thank you for FreeOTP, Nathaniel and co.
> 
> And, of course, more thankful to all the Identity open source/free
> software from this awesome team!
> 
> A happy user.
> 

Thanks Kashyap,
really appreciated.

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



On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. 
SoftHsm has
one component Softdatabase with an API, which more or less 
passes sets
of attributes (attributes defined by PKCS#11) and then stores 
it as

records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be 
the most

straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we 
can

use
a single attribute containing PKCS#8 encoded private key rather 
than

using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate 
objects.


So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact 
that we

want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway: 
.


Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is 
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token 
user", "authority" and "other entity". We could map entries with 
object class pkiUser to certificate object with 
CKA_CERTIFICATE_CATEGORY "token user" and entries with object class 
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY "authority". 
There are no object classes in RFC 4523 for "unspecified" and "other 
entity", but we will not be storing any certificates using PKCS#11 
anyway, so I think it's OK.
not sure I understand what exactly you want here. If we don't store 
certificates using the pkcs#11 schema we don't need to define them, but 
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. 
Do you mean to have a pkcs11 cerificate object with 
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes 
userCertificate and cACertificate to store them ?


Also the above got me thinking, is there any "standard" LDAP schema 
for private keys? If so, can we use it?
I didn't find any, the only keys in ldap I found is a definition for 
sshPublicKey for openssh.


I'm going to store NSS trust objects along with CA certificates, so 
I'm going to need an object class for that. You can find the details 
on CKO_NSS_TRUST at 
.


If we store multiple related PKCS#11 objects in a single LDAP entry, 
there is going to be some redundancy. For example, public key value 
can be extracted from private key value, so we don't need to store 
both of the values. This can be bypassed by having separate object 
classes for data and for metadata. For a key pair entry, the object 
classes would be e.g. privateKey, pkcs11privateKey and 
pkcs11publicKey, where privateKey is an object class with private key 
data (without any PKCS#11 bits), pkcs11privateKey is an object class 
with PKCS#11 private key metadata and pkcs11publicKey is an object 
class with PKCS#11 public key metadata. In the PKCS#11 module, this 
entry would be visible as two separate objects (private key object and 
public key object).
I have not yet rewritten the objectcalss definition after the latest 
discussion, but I think if we have one structural objectclass 
pkcs11storageObject with only a uniqueid and auxiliary objectclasses for 
publickey,privatekey, certificate where the attributes (maybe 
withexception of label, id) are optional there will be no redundancy, 
store only what is needed.
you could use these aux objectclass also in other entries instead of 
using pkcs11storageObject.


Regarding PKCS#11 metadata attributes (i.e. excluding certificate, 
private key and public key value attributes), I think they all should 
be single-valued. Comments on specific attributes:


  * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, 
CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, 
CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECH

[Freeipa-devel] [PATCH][bind-dyndb-ldap] AUTOCONF: Improve detection of bind9 header files

2014-02-27 Thread Lukas Slebodnik

ehlo,

I did some reviews of bind-dyndb-ldap last week  and it was little bit annoying
to export special CFLAGS for bind9 header files. It can be automatically
detected in configure script using utility isc-config.

Attached patch should improve this and CFLAGS needn't be exported.

LS
>From 118301596dadc2ef66437e7c6661c5fb84459611 Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik 
Date: Tue, 25 Feb 2014 10:46:50 +0100
Subject: [PATCH] AUTOCONF: Improve detection of bind9 header files

bind9 header files are stored in non-default path (/usr/include/bind9)
There is an utility (isc-config) which can provides cflags.
---
 configure.ac | 30 +-
 contrib/bind-dyndb-ldap.spec |  1 -
 src/Makefile.am  |  3 ++-
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 
91739c03d9d6de2a9c07129ff0d71b024953293b..5b860f62208fae01cd3ee4cb9b585bf89416e5cf
 100644
--- a/configure.ac
+++ b/configure.ac
@@ -62,7 +62,35 @@ int main(void) {
 [AC_MSG_ERROR([Cross compiling is not supported.])]
 )
 
-# Older autoconf (2.59, for example) doesn't define docdir
+AC_SUBST(BIND9_CFLAGS)
+AC_SUBST(BIND9_LIBS)
+
+AC_PATH_PROG(ISC_CONFIG, [isc-config.sh])
+AC_MSG_CHECKING([for working isc-config])
+if test -x "$ISC_CONFIG"; then
+AC_MSG_RESULT([yes]);
+
+dnl do not override enviroment variables BIND9_CFLAGS BIND9_LIBS
+if test -z "$BIND9_CFLAGS"; then
+BIND9_CFLAGS=`$ISC_CONFIG --cflags dns`
+fi
+dnl We do not need all libraries suggested by isc-config.sh
+dnl {-lcrypto, -lcap} are useless
+dnl BIND9_LIBS=`$ISC_CONFIG --libs dns`
+else
+AC_MSG_RESULT([no])
+AC_MSG_WARN([
+Could not detect script isc-config.sh. Compilation may fail.
+Defining variables BIND9_CFLAGS BIND9_LIBS will fix this problem.
+])
+fi
+
+AC_ARG_VAR([BIND9_CFLAGS],
+   [C compiler flags for bind9, overriding isc-config.sh])
+AC_ARG_VAR([BIND9_LIBS],
+   [linker flags for bind9, overriding isc-config.sh])
+
+dnl Older autoconf (2.59, for example) doesn't define docdir
 [[ ! -n "$docdir" ]] && docdir='${datadir}/doc/${PACKAGE_TARNAME}'
 AC_SUBST([docdir])
 
diff --git a/contrib/bind-dyndb-ldap.spec b/contrib/bind-dyndb-ldap.spec
index 
b345b1b5cb6cad99cf2f1c4df7d9f1e2b144548d..12b8004e218a06606a242255ac87b8f2736225ac
 100644
--- a/contrib/bind-dyndb-ldap.spec
+++ b/contrib/bind-dyndb-ldap.spec
@@ -27,7 +27,6 @@ off of your LDAP server.
 %setup -q -n %{name}-%{VERSION}
 
 %build
-export CFLAGS="`isc-config.sh --cflags dns` $RPM_OPT_FLAGS"
 %configure
 make %{?_smp_mflags}
 
diff --git a/src/Makefile.am b/src/Makefile.am
index 
6856957f48dbe32750009ab8a32487add05d5c1c..4adf28a2dcdc09223d86c367fad492f7d64a2b13
 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -43,6 +43,7 @@ ldap_la_SOURCES = \
zone_manager.c  \
zone_register.c
 
-ldap_la_CFLAGS = -Wall -Wextra @WERROR@ -std=gnu99 -O2
+ldap_la_CFLAGS = $(BIND9_CFLAGS) -Wall -Wextra @WERROR@ -std=gnu99
 
+ldap_la_LIBADD = $(BIND9_LIBS)
 ldap_la_LDFLAGS = -module -avoid-version -Wl,-z,relro,-z,now,-z,noexecstack
-- 
1.8.5.3

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0143: catch access denial when removing old trust object when using non-privileged AD user to create trust

On 02/26/2014 04:54 PM, Alexander Bokovoy wrote:
> Hi,
> 
> this patch fixes a case when non-privileged AD user account is used to
> re-establish trust. We need to catch one specific exception in deleting
> the old trust and bail out earlier with proper error message.
> 
> https://fedorahosted.org/freeipa/ticket/4202

Works fine, ACK. Pushed to:
master: 3a7ba6013ffe43176bcff2c716b33552853847ff
ipa-3-3: 42108d1c0dc552e5dbc249507bfe59a1ef1d4c8e

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Is there RPC documentation?


Rich Megginson wrote:

On 02/26/2014 03:48 PM, Simo Sorce wrote:

On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:

On 02/26/2014 03:22 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack
designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
communicate with freeipa.  Is there documentation about how to
construct
and send RPC messages?

The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will
print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/






Ok.  Next question is - how does one do the equivalent of the curl
command in python code?

Here is a pretty stripped-down way to add a user. Other commands are
similar, you just may care more about the output:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
 api.Command['user_add'](u'testuser',
 givenname=u'Test', sn=u'User',
 loginshell=u'/bin/sh')
except errors.DuplicateEntry:
 print "user already exists"
else:
 print "User added"


How would one do this from outside of ipa?  If ipalib is not
available?

You'd need to go to either /ipa/xml or /ipa/json (depending on what
protocol you want to use) and issue one request there. This requires
Kerberos authentication. The response will include a cookie which you
should either ignore or store safely (like in the kernel keyring).
Using the cookie will significantly improve performance.

This is for the ipa dns backend for designate.  I'm assuming I will
either be using a keytab, or perhaps the new proxy?

At any rate, I have to do everything in python - including the kinit
with the keytab.

Lok at rob's damon but you should *not* do a kinit, you should just use
gssapi (see python-kerberos) and do a gss_init_sec_context there, if the
environment is configured (KRB5_KTNAME set correctly) then gssapi will
automatically kinit for you under the hood.


I guess I'm really looking for specifics - I've seen recommendations to
use the python libraries "requests" and "json".  I don't know if
requests supports negotiate/kerberos.  If not, is there a recommended
library to use?  As this particular project will be part of openstack,
perhaps there is a more "openstack"-y library, or even something
built-in to openstack (oslo?).  I think amqp support kerberos, so
perhaps there is some oslo.messaging thing that will do the http +
kerberos stuff.

Afaik there is nothing that does kerberos in openstack, you'll have to
introduce all that stuff.


Egads - implementing openstack-wide kerberos client libraries in order
to add an ipa dns backend to designate.

Rob, need any help with your proxy?


Well, something occurred to me this morning. You need SSL on top of this 
too, which means you need the IPA CA. The easiest way to get that is to 
enroll the designate server as an IPA client. This pulls in the 
freeipa-python package which gives you ipalib, so no reinventing the 
wheel required.


rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0144: trust: make sure we always discover topology of the forest trust

On 02/27/2014 01:43 PM, Alexander Bokovoy wrote:
> On Thu, 27 Feb 2014, Martin Kosek wrote:
>> On 02/27/2014 12:48 PM, Alexander Bokovoy wrote:
>>> Thanks to Martin for noticing we had been fetching information about
>>> subdomains only in case there is algorithmic ID mapping in use. Instead,
>>> we should always fetch the subdomains but create new ranges only for
>>> algorithmic case.
>>>
>>> https://fedorahosted.org/freeipa/ticket/4205
>>>
>>
>> This works fine for the trustdomain part. However, we still create too many 
>> ID
>> ranges:
>>
>>
>> # ipa idrange-find
>> 
>> 3 ranges matched
>> 
>>  Range name: CHILD.TBAD.EXAMPLE.COM_id_range
>>  First Posix ID of the range: 16100
>>  Number of IDs in the range: 20
>>  First RID of the corresponding RID range: 0
>>  Domain SID of the trusted domain: S-1-5-21-972585150-1048339146-1910910075
>>  Range type: Active Directory domain range
>>
>>  Range name: IDM.LAB.BOS.REDHAT.COM_id_range
>>  First Posix ID of the range: 125860
>>  Number of IDs in the range: 20
>>  First RID of the corresponding RID range: 1000
>>  First RID of the secondary RID range: 1
>>  Range type: local domain range
>>
>>  Range name: TBAD.EXAMPLE.COM_id_range
>>  First Posix ID of the range: 1
>>  Number of IDs in the range: 20
>>  First RID of the corresponding RID range: 0
>>  Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726
>>  Range type: Active Directory trust range with POSIX attributes
>> 
>> Number of entries returned 3
>> 
>>
>> CHILD.TBAD.EXAMPLE.COM_id_range should not be here given this is a POSIX 
>> trust.
> 
> Yes. We tracked this down to a wrong code in fetch_domains_from_trust()
> where instead of a final value we took a list that contained the value
> and compared it for inequality with a unicode value. Of course, the
> comparison always evaluated to true (list is not a unicode object).
> 
> New patch is attached. It removes duplicated code from the trust-add as
> the same action (adding idranges for subdomains) is done in
> fetch_domains_from_trust().

Good we have it now just on one place. Worked fine for me, thanks.

ACK. Pushed to master, ipa-3-3.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC design page


On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can
use
a single attribute containing PKCS#8 encoded private key rather than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact that we
want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway: 
.


Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is 
CKA_CERTIFICATE_CATEGORY which can have values "unspecified", "token 
user", "authority" and "other entity". We could map entries with object 
class pkiUser to certificate object with CKA_CERTIFICATE_CATEGORY "token 
user" and entries with object class pkiCA to certificate object with 
CKA_CERTIFICATE_CATEGORY "authority". There are no object classes in RFC 
4523 for "unspecified" and "other entity", but we will not be storing 
any certificates using PKCS#11 anyway, so I think it's OK.


Also the above got me thinking, is there any "standard" LDAP schema for 
private keys? If so, can we use it?


I'm going to store NSS trust objects along with CA certificates, so I'm 
going to need an object class for that. You can find the details on 
CKO_NSS_TRUST at 
.


If we store multiple related PKCS#11 objects in a single LDAP entry, 
there is going to be some redundancy. For example, public key value can 
be extracted from private key value, so we don't need to store both of 
the values. This can be bypassed by having separate object classes for 
data and for metadata. For a key pair entry, the object classes would be 
e.g. privateKey, pkcs11privateKey and pkcs11publicKey, where privateKey 
is an object class with private key data (without any PKCS#11 bits), 
pkcs11privateKey is an object class with PKCS#11 private key metadata 
and pkcs11publicKey is an object class with PKCS#11 public key metadata. 
In the PKCS#11 module, this entry would be visible as two separate 
objects (private key object and public key object).


Regarding PKCS#11 metadata attributes (i.e. excluding certificate, 
private key and public key value attributes), I think they all should be 
single-valued. Comments on specific attributes:


  * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, 
CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, 
CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, 
CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, 
CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP 
attributes for these, for the sake of completeness


  * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in 
LDAP are always persistent, so there is no need for pkcs11token


  * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for 
pkcs11certificateType


  * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object 
classes (see above), we don't need an LDAP attribute for it


  * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, 
CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from 
certificate value, no need for LDAP attributes


  * CKA_URL - do we want to support certificates with URL instead of value?

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0144: trust: make sure we always discover topology of the forest trust


On Thu, 27 Feb 2014, Martin Kosek wrote:

On 02/27/2014 12:48 PM, Alexander Bokovoy wrote:

Thanks to Martin for noticing we had been fetching information about
subdomains only in case there is algorithmic ID mapping in use. Instead,
we should always fetch the subdomains but create new ranges only for
algorithmic case.

https://fedorahosted.org/freeipa/ticket/4205



This works fine for the trustdomain part. However, we still create too many ID
ranges:


# ipa idrange-find

3 ranges matched

 Range name: CHILD.TBAD.EXAMPLE.COM_id_range
 First Posix ID of the range: 16100
 Number of IDs in the range: 20
 First RID of the corresponding RID range: 0
 Domain SID of the trusted domain: S-1-5-21-972585150-1048339146-1910910075
 Range type: Active Directory domain range

 Range name: IDM.LAB.BOS.REDHAT.COM_id_range
 First Posix ID of the range: 125860
 Number of IDs in the range: 20
 First RID of the corresponding RID range: 1000
 First RID of the secondary RID range: 1
 Range type: local domain range

 Range name: TBAD.EXAMPLE.COM_id_range
 First Posix ID of the range: 1
 Number of IDs in the range: 20
 First RID of the corresponding RID range: 0
 Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726
 Range type: Active Directory trust range with POSIX attributes

Number of entries returned 3


CHILD.TBAD.EXAMPLE.COM_id_range should not be here given this is a POSIX trust.


Yes. We tracked this down to a wrong code in fetch_domains_from_trust()
where instead of a final value we took a list that contained the value
and compared it for inequality with a unicode value. Of course, the
comparison always evaluated to true (list is not a unicode object).

New patch is attached. It removes duplicated code from the trust-add as
the same action (adding idranges for subdomains) is done in
fetch_domains_from_trust().


--
/ Alexander Bokovoy
>From 538812b7efa90556a6ccbc72fabeddeaca51c27d Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 27 Feb 2014 13:43:17 +0200
Subject: [PATCH 8/8] trust: make sure we always discover topology of the
 forest trust

Even though we are creating idranges for subdomains only in case
there is algorithmic ID mapping in use, we still need to fetch
list of subdomains for all other cases.

https://fedorahosted.org/freeipa/ticket/4205
---
 ipalib/plugins/trust.py | 37 ++---
 1 file changed, 6 insertions(+), 31 deletions(-)

diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index bd71253..f2b00a6 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -458,38 +458,13 @@ sides.
 
 result['result'] = entry_to_dict(trusts[0][1], **options)
 
-# For AD trusts with algorithmic mapping, we need to add a separate
-# range for each subdomain.
-if (options.get('trust_type') == u'ad' and
-created_range_type != u'ipa-ad-trust-posix'):
-
+# Fetch topology of the trust forest -- we need always to do it
+# for AD trusts, regardless of the type of idranges associated with it
+# Note that fetch_domains_from_trust will add needed ranges for
+# the algorithmic ID mapping case.
+if options.get('trust_type') == u'ad':
 domains = fetch_domains_from_trust(self, self.trustinstance,
result['result'], **options)
-if domains and len(domains) > 0:
-for dom in domains:
-range_name = dom['cn'][0].upper() + '_id_range'
-dom_sid = dom['ipanttrusteddomainsid'][0]
-
-# Enforce the same range type as the range for the root
-# level domain.
-
-# This will skip the detection of the POSIX attributes if
-# they are not available, since it has been already
-# detected when creating the range for the root level 
domain
-passed_options = options
-passed_options.update(range_type=created_range_type)
-
-# Do not pass the base id to the subdomains since it would
-# clash with the root level domain
-if 'base_id' in passed_options:
-del passed_options['base_id']
-
-# Try to add the range for each subdomain
-try:
-add_range(self, range_name, dom_sid, *keys,
-  **passed_options)
-except errors.DuplicateEntry:
-pass
 
 # Format the output into human-readable values
 result['result']['trusttype'] = [trust_type_string(
@@ -1270,7 +1245,7 @@ def fetch_domains_from_trust(self, trustinstance, 
trust_entry, **options):
 # trust range must exist by the time fet

Re: [Freeipa-devel] [PATCH] 531-541 OTP UI

2014-02-27 Thread Petr Vobornik


On 21.2.2014 15:24, Petr Vobornik wrote:

On 10.2.2014 14:12, Petr Vobornik wrote:

On 13.1.2014 17:09, Petr Vobornik wrote:

Hi,

these patches implements the OTP Web UI.

Last 5 patches is the OTP UI.

First 6 patches is a little refactoring/bug fixes needed for them.
General password dialog is introduced to avoid another implementation.

Self-service UI is implemented to be very simple. Atm user can choose
only token name. Admin interface allows to enter all values.

It's based on the RCUE work -> we need to push RCUE first. Thanks
Nathaniel for review of the last font package. It will speed things up.

Know bugs:
- there is clash in id's of checkboxes preventing editation of
subsequently displayed ones with the same name. Will be fixed in
separate patch.
- bugs caused by bugs in API (adding/removal of own tokens in
self-service, inability to enter key on token creation -
https://fedorahosted.org/freeipa/ticket/4099)
- datetime format (widget+validator) will be implemented in separate
patch
- no support of not reviewed CLI patches (HOTP..)

Cgit:
http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp

https://fedorahosted.org/freeipa/ticket/3369



patch 540-1 has been updated
- QR code is centered
- QR code correction level was lowered from H to M

All other current patches from sub-threads are attached as well (it was
getting hard to keep track of them).



Attaching new version of patch 537: 537-4

It:
* adds HOTP support - new switch in adder dialog and ipatokenhotpcounter
field in details facet
* removes 'default' radio button in adder dialog in ipatokenotpalgorithm
and ipatokenotpdigits field


Btw I've encountered an issue on Web UI login when:
- user is created
- token is created for him
- admin resets user's password and changes auth type to 'otp'
- user tries to login with psw+otp

The initial login-password call is successful but subsequent change
password fails - it uses the old psw+otp.

I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903
which is almost implemented.


I also plan to hide fields without any value in otp token details page
in self-service mode. This will be done after #3903 because some
prerequisites for #3903 add useful code for that task.



New version of 537 attached: 537-5

It removes token type switch from selfservice page. Therefore default 
token type (totp) will be always created.


Originated from: 
http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html

--
Petr Vobornik
From 363b47b6e51a95b63ce38be047e6043f48c86e47 Mon Sep 17 00:00:00 2001
From: Petr Vobornik 
Date: Thu, 12 Sep 2013 15:29:01 +0200
Subject: [PATCH] UI for OTP tokens

https://fedorahosted.org/freeipa/ticket/3369
---
 install/ui/doc/categories.json |   1 +
 install/ui/src/freeipa/app.js  |   1 +
 install/ui/src/freeipa/navigation/menu_spec.js |  10 +-
 install/ui/src/freeipa/otptoken.js | 314 +
 install/ui/src/freeipa/search.js   |  18 +-
 install/ui/test/data/ipa_init.json |   5 +
 ipalib/plugins/internal.py |   9 +-
 7 files changed, 347 insertions(+), 11 deletions(-)
 create mode 100644 install/ui/src/freeipa/otptoken.js

diff --git a/install/ui/doc/categories.json b/install/ui/doc/categories.json
index 9f04c4b28bd889947926faa990653e023b8954b0..02487e542c64eb1ab3dac76f497c186f41fe489b 100644
--- a/install/ui/doc/categories.json
+++ b/install/ui/doc/categories.json
@@ -218,6 +218,7 @@
 "name": "Plugins",
 "classes": [
 "aci",
+"otptoken",
 "user"
 ]
 }
diff --git a/install/ui/src/freeipa/app.js b/install/ui/src/freeipa/app.js
index 2fbe0775c4dd58ed4a741a222323de82b7eb92f7..05bef374f4b25f4f052d9f107291c5b7a0914bbc 100644
--- a/install/ui/src/freeipa/app.js
+++ b/install/ui/src/freeipa/app.js
@@ -41,6 +41,7 @@ define([
 './host',
 './idrange',
 './netgroup',
+'./otptoken',
 './policy',
 './realmdomains',
 './rule',
diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js
index 9d4c5eff9b6c2b5a64a2f83f73fcec87aef7443d..e531a9f6d4446b1d395b6bb6dfd011877ac61530 100644
--- a/install/ui/src/freeipa/navigation/menu_spec.js
+++ b/install/ui/src/freeipa/navigation/menu_spec.js
@@ -56,7 +56,8 @@ var nav = {};
 ]
 },
 { entity: 'cert', label: '@i18n:tabs.cert' },
-{ entity: 'realmdomains' }
+{ entity: 'realmdomains' },
+{ entity: 'otptoken' }
 ]
 },
 {name: 'policy', label: '@i18n:tabs.policy', children: [
@@ -148,10 +149,13 @@ nav.self_service = {
 {
 name: 'identity',
 label: '@i18n:tabs.identity',
-children: [{entity: 'user'}]
+children: [
+{ entity:

Re: [Freeipa-devel] [PATCH] 0144: trust: make sure we always discover topology of the forest trust

On 02/27/2014 12:48 PM, Alexander Bokovoy wrote:
> Thanks to Martin for noticing we had been fetching information about
> subdomains only in case there is algorithmic ID mapping in use. Instead,
> we should always fetch the subdomains but create new ranges only for
> algorithmic case.
> 
> https://fedorahosted.org/freeipa/ticket/4205
> 

This works fine for the trustdomain part. However, we still create too many ID
ranges:


# ipa idrange-find

3 ranges matched

  Range name: CHILD.TBAD.EXAMPLE.COM_id_range
  First Posix ID of the range: 16100
  Number of IDs in the range: 20
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-972585150-1048339146-1910910075
  Range type: Active Directory domain range

  Range name: IDM.LAB.BOS.REDHAT.COM_id_range
  First Posix ID of the range: 125860
  Number of IDs in the range: 20
  First RID of the corresponding RID range: 1000
  First RID of the secondary RID range: 1
  Range type: local domain range

  Range name: TBAD.EXAMPLE.COM_id_range
  First Posix ID of the range: 1
  Number of IDs in the range: 20
  First RID of the corresponding RID range: 0
  Domain SID of the trusted domain: S-1-5-21-2997650941-1802118864-3094776726
  Range type: Active Directory trust range with POSIX attributes

Number of entries returned 3


CHILD.TBAD.EXAMPLE.COM_id_range should not be here given this is a POSIX trust.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 0230] Remove release tag from BIND dependency

2014-02-27 Thread Petr Spacek


Hello,

Remove release tag from BIND dependency.

This change should allow to build v3 branch on RHEL/CentOS 6.

Pushed to v3 branch 2ec56086e811a2247e7a75b5eb5d4784751cb2a5.

--
Petr^2 Spacek
From 2ec56086e811a2247e7a75b5eb5d4784751cb2a5 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Thu, 27 Feb 2014 10:35:11 +0100
Subject: [PATCH] Remove release tag from BIND depedency.

Signed-off-by: Petr Spacek 
---
 contrib/bind-dyndb-ldap.spec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/bind-dyndb-ldap.spec b/contrib/bind-dyndb-ldap.spec
index 3c364aa0b1a1dfe0b6de81ceaf3ef971cad9bdf8..6343b6cb2e85e6dd65a318b1be295351a291249c 100644
--- a/contrib/bind-dyndb-ldap.spec
+++ b/contrib/bind-dyndb-ldap.spec
@@ -11,11 +11,11 @@ URL:https://fedorahosted.org/bind-dyndb-ldap
 Source0:https://fedorahosted.org/released/%{name}/%{name}-%{VERSION}.tar.bz2
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
-BuildRequires:  bind-devel >= 32:9.8.2-1
+BuildRequires:  bind-devel >= 32:9.8.2
 BuildRequires:  krb5-devel
 BuildRequires:  openldap-devel
 
-Requires:   bind >= 32:9.8.2-1
+Requires:   bind >= 32:9.8.2
 
 %description
 This package provides an LDAP back-end plug-in for BIND. It features
-- 
1.8.5.3

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0478 ipalib.plugins: Expose LDAPObjects' eligibility for permission --type in JSON metadata


On 02/27/2014 12:52 PM, Alexander Bokovoy wrote:

On Thu, 27 Feb 2014, Petr Viktorin wrote:

Hello,
This patch exposes object metadata needed for permission WebUI.

https://fedorahosted.org/freeipa/ticket/4201

--
Petr³



From cbebd3328715db4ddd4afe9bdbd6c6edf0bf7148 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Wed, 26 Feb 2014 16:39:49 +0100
Subject: [PATCH] ipalib.plugins: Expose LDAPObjects' eligibility for
permission --type in JSON metadata

https://fedorahosted.org/freeipa/ticket/4201
---
ipalib/plugins/baseldap.py | 2 ++
1 file changed, 2 insertions(+)

diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index
c2aad784df2b2bcd03f4ec0462e74cd6abce594c..c4951eb56c044cfa08b617d546d9b9332adc4cc9
100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -631,6 +631,8 @@ def __json__(self):
json_dict['aciattrs'] = attrlist
attrlist.sort()
json_dict['methods'] = [m for m in self.methods]
+json_dict['can_have_permissions'] = bool(
+self.permission_filter_objectclasses)
return json_dict

ACK.




Pushed to master: 4fda432050e9b12ec9d48c2c80b9fd69faa54480


--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0156] trusts: Remove usage of deprecated LDAP API


On 02/27/2014 12:51 PM, Alexander Bokovoy wrote:

On Thu, 27 Feb 2014, Tomas Babej wrote:

Hi,

Remove a reference to the old deprecated LDAP API invoked by
the usage of trust_add method.

https://fedorahosted.org/freeipa/ticket/4204

--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org





From ee59e86f5ee91da97de0484fdcc9b40590844f76 Mon Sep 17 00:00:00 2001

From: Tomas Babej 
Date: Thu, 27 Feb 2014 10:33:50 +0100
Subject: [PATCH] trusts: Remove usage of deprecated LDAP API

Remove a reference to the old deprecated LDAP API invoked by
the usage of trust_add method.

https://fedorahosted.org/freeipa/ticket/4204
---
ipaserver/dcerpc.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index
5cc168be4717bf40d5ae31532828488e3a3a819e..c3ae00ef3d089d3617809b4cc81153e0704890b7
100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -1102,9 +1102,9 @@ class TrustDomainJoins(object):

realm_domains = self.api.Command.realmdomains_show()['result']
# Use realmdomains' modification timestamp to judge records
last update time
-(dn, entry_attrs) =
self.api.Backend.ldap2.get_entry(realm_domains['dn'],
['modifyTimestamp'])
+entry = self.api.Backend.ldap2.get_entry(realm_domains['dn'],
['modifyTimestamp'])
# Convert the timestamp to Windows 64-bit timestamp format
-trust_timestamp =
long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14],
"%Y%m%d%H%M%S"))*1e7+1164447360)
+trust_timestamp =
long(time.mktime(time.strptime(entry['modifytimestamp'][0][:14],
"%Y%m%d%H%M%S"))*1e7+1164447360)

for dom in realm_domains['associateddomain']:
ftinfo = dict()

ACK.




Pushed to master: 96f87e548af5107e33f33cdb3af9fd542d0aa413


--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0478 ipalib.plugins: Expose LDAPObjects' eligibility for permission --type in JSON metadata


On Thu, 27 Feb 2014, Petr Viktorin wrote:

Hello,
This patch exposes object metadata needed for permission WebUI.

https://fedorahosted.org/freeipa/ticket/4201

--
Petr³



From cbebd3328715db4ddd4afe9bdbd6c6edf0bf7148 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Wed, 26 Feb 2014 16:39:49 +0100
Subject: [PATCH] ipalib.plugins: Expose LDAPObjects' eligibility for
permission --type in JSON metadata

https://fedorahosted.org/freeipa/ticket/4201
---
ipalib/plugins/baseldap.py | 2 ++
1 file changed, 2 insertions(+)

diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 
c2aad784df2b2bcd03f4ec0462e74cd6abce594c..c4951eb56c044cfa08b617d546d9b9332adc4cc9
 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -631,6 +631,8 @@ def __json__(self):
json_dict['aciattrs'] = attrlist
attrlist.sort()
json_dict['methods'] = [m for m in self.methods]
+json_dict['can_have_permissions'] = bool(
+self.permission_filter_objectclasses)
return json_dict

ACK.


--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0156] trusts: Remove usage of deprecated LDAP API


On Thu, 27 Feb 2014, Tomas Babej wrote:

Hi,

Remove a reference to the old deprecated LDAP API invoked by
the usage of trust_add method.

https://fedorahosted.org/freeipa/ticket/4204

--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org





From ee59e86f5ee91da97de0484fdcc9b40590844f76 Mon Sep 17 00:00:00 2001

From: Tomas Babej 
Date: Thu, 27 Feb 2014 10:33:50 +0100
Subject: [PATCH] trusts: Remove usage of deprecated LDAP API

Remove a reference to the old deprecated LDAP API invoked by
the usage of trust_add method.

https://fedorahosted.org/freeipa/ticket/4204
---
ipaserver/dcerpc.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index 
5cc168be4717bf40d5ae31532828488e3a3a819e..c3ae00ef3d089d3617809b4cc81153e0704890b7
 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -1102,9 +1102,9 @@ class TrustDomainJoins(object):

realm_domains = self.api.Command.realmdomains_show()['result']
# Use realmdomains' modification timestamp to judge records last update 
time
-(dn, entry_attrs) = 
self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp'])
+entry = self.api.Backend.ldap2.get_entry(realm_domains['dn'], 
['modifyTimestamp'])
# Convert the timestamp to Windows 64-bit timestamp format
-trust_timestamp = 
long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14], 
"%Y%m%d%H%M%S"))*1e7+1164447360)
+trust_timestamp = 
long(time.mktime(time.strptime(entry['modifytimestamp'][0][:14], 
"%Y%m%d%H%M%S"))*1e7+1164447360)

for dom in realm_domains['associateddomain']:
ftinfo = dict()

ACK.


--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 0144: trust: make sure we always discover topology of the forest trust


Thanks to Martin for noticing we had been fetching information about
subdomains only in case there is algorithmic ID mapping in use. Instead,
we should always fetch the subdomains but create new ranges only for
algorithmic case.

https://fedorahosted.org/freeipa/ticket/4205
--
/ Alexander Bokovoy
>From f2cca17e5e9fa601934cc2b1bbae984b81195adb Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 27 Feb 2014 13:43:17 +0200
Subject: [PATCH 8/8] trust: make sure we always discover topology of the
 forest trust

Even though we are creating idranges for subdomains only in case
there is algorithmic ID mapping in use, we still need to fetch
list of subdomains for all other cases.

https://fedorahosted.org/freeipa/ticket/4205
---
 ipalib/plugins/trust.py | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index bd71253..ed91dac 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -458,13 +458,15 @@ sides.
 
 result['result'] = entry_to_dict(trusts[0][1], **options)
 
+# Fetch topology of the trust forest -- we need always to do it
+# for AD trusts, regardless of the type of idranges associated with it
+if options.get('trust_type') == u'ad':
+domains = fetch_domains_from_trust(self, self.trustinstance,
+   result['result'], **options)
 # For AD trusts with algorithmic mapping, we need to add a separate
 # range for each subdomain.
 if (options.get('trust_type') == u'ad' and
 created_range_type != u'ipa-ad-trust-posix'):
-
-domains = fetch_domains_from_trust(self, self.trustinstance,
-   result['result'], **options)
 if domains and len(domains) > 0:
 for dom in domains:
 range_name = dom['cn'][0].upper() + '_id_range'
-- 
1.8.3.1

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 0478 ipalib.plugins: Expose LDAPObjects' eligibility for permission --type in JSON metadata


Hello,
This patch exposes object metadata needed for permission WebUI.

https://fedorahosted.org/freeipa/ticket/4201

--
Petr³
From cbebd3328715db4ddd4afe9bdbd6c6edf0bf7148 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Wed, 26 Feb 2014 16:39:49 +0100
Subject: [PATCH] ipalib.plugins: Expose LDAPObjects' eligibility for
 permission --type in JSON metadata

https://fedorahosted.org/freeipa/ticket/4201
---
 ipalib/plugins/baseldap.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index c2aad784df2b2bcd03f4ec0462e74cd6abce594c..c4951eb56c044cfa08b617d546d9b9332adc4cc9 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -631,6 +631,8 @@ def __json__(self):
 json_dict['aciattrs'] = attrlist
 attrlist.sort()
 json_dict['methods'] = [m for m in self.methods]
+json_dict['can_have_permissions'] = bool(
+self.permission_filter_objectclasses)
 return json_dict
 
 
-- 
1.8.5.3

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 6 webui: Too big font in input fields

2014-02-27 Thread Petr Vobornik

On 26.2.2014 18:24, Adam Misnyovszki wrote:

- Original Message -

From: "Petr Vobornik" 
To: "Adam Misnyovszki" , freeipa-devel@redhat.com, "Martin 
Kosek" 
Sent: Wednesday, February 26, 2014 2:32:52 PM
Subject: Re: [Freeipa-devel] [PATCH] Too big font in input fields

On 26.2.2014 13:00, Adam Misnyovszki wrote:

Hi,
too big font issue in ipa-3-3 and Firefox 27 fixed:

In Firefox 27, default font size has bigger priority than body css,
text input font size is therefore explicitly set to 1em

https://fedorahosted.org/freeipa/ticket/4180

Thanks:
Adam

NACK

The issue is not present only in textboxes but also in comboboxes and
selects. Btw, why the height: 12px?

It was because FF overwritten not only the font-size, but also the font-family. 
Fixed.

I suggest to use:

input, select, textarea {
  font-size: 1em
}

this should set the defaults for the whole UI.

Done.

In other topic Dmitri complained about ugliness of trust UI in 3.3
because of jammed radios and labels. Martin, can we steal this CSS
ticket and fix it with?

input[type=radio], input[type=checkbox],
.ui-widget input[type=radio], .ui-widget input[type=checkbox]{
  margin-right: 5px;
  position: relative;
  top: 2px;
}
--
Petr Vobornik

Done.

Thanks
Adam

ACK

pushed to ipa-3-3: dceaced929e99d732a3a4d6868ee2bff8fbee168
--
Petr Vobornik

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified

On 02/27/2014 11:06 AM, Alexander Bokovoy wrote:
> On Thu, 27 Feb 2014, Martin Kosek wrote:
>> On 02/26/2014 05:03 PM, Alexander Bokovoy wrote:
>>> On Wed, 26 Feb 2014, Martin Kosek wrote:
 On 02/25/2014 06:56 PM, Alexander Bokovoy wrote:
> Hi,
>
> Simple patch to fix KeyError as --pkey-only causes no attributes to be
> returned and trustdomain_find.post_callback checked them
> unconditionally.
>
>
> https://fedorahosted.org/freeipa/ticket/4196

 Can we simply skip the whole loop when options.get('pkey_only', False)? 
 I.e.:

def post_callback(self, ldap, entries, truncated, *args, **options):
if not options.get('pkey_only', False):
trust_dn = self.obj.get_dn(args[0], trust_type=u'ad')
trust_entry = ldap.get_entry(trust_dn)
...

 It seems to me that your way we still do one unnecessary LDAP search which 
 is
 never used. With pkey_only we should not be filling anything in 
 post_callback
 at all if it is not affecting the pkey.
>>> Right, new patch attached.
>>>
>>
>> It still crashes:
>>
>> [Thu Feb 27 04:55:51.245147 2014] [:error] [pid 3479] Traceback (most recent
>> call last):
>> [Thu Feb 27 04:55:51.245149 2014] [:error] [pid 3479]   File
>> "/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", line 333,
>> in wsgi_execute
>> [Thu Feb 27 04:55:51.245152 2014] [:error] [pid 3479] result =
>> self.Command[name](*args, **options)
>> [Thu Feb 27 04:55:51.245155 2014] [:error] [pid 3479]   File
>> "/usr/lib/python2.7/site-packages/ipalib/  frontend.py", line 447, in 
>> __call__
>> [Thu Feb 27 04:55:51.245157 2014] [:error] [pid 3479]
>> self.validate_output(ret)
>> [Thu Feb 27 04:55:51.245159 2014] [:error] [pid 3479]   File
>> "/usr/lib/python2.7/site-packages/ipalib/  frontend.py", line 947, in
>> validate_output
>> [Thu Feb 27 04:55:51.245162 2014] [:error] [pid 3479] nice, o.name, 
>> o.type,
>> type(value), value)
>> [Thu Feb 27 04:55:51.245164 2014] [:error] [pid 3479] TypeError:
>> trustdomain_find.validate_output():
>> [Thu Feb 27 04:55:51.245167 2014] [:error] [pid 3479]   output['truncated']:
>> need ; got
>>
>>
>> You need to "return truncated", not just "return". When this is changed, 
>> patch
>> works as expected.
> Yep, thanks!
> 
> New patch attached.
> 

ACK. Pushed to master, ipa-3-3.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC design page


On 27.2.2014 11:28, Ludwig Krispenz wrote:


On 02/27/2014 10:17 AM, Jan Cholasta wrote:

On 26.2.2014 17:37, Petr Spacek wrote:

On 26.2.2014 15:20, Ludwig Krispenz wrote:

I was talking about 'layer of indirection' previously. I'm digging
into
details and it seems like a good idea to imitate what DNS
registrars do
- use concept of key sets. It means that keys are not linked to a
zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a
key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies
for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to
keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and
idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key
generated
by OpenDNSSEC? Are you suggesting having a separate slot/token for
each
keyset? I would like to keep the number of tokens low, because
there are
applications which go slot by slot, token by token when searching for
objects (e.g. BIND and OpenSSH) and that might generate a lot of
unnecessary
traffic if the number of slots/tokens is high.

Okay, then we can store all DNSSEC keys in one slot and use "key sets"
only for administrative purposes (i.e. pairing zone <=> keys in BIND)
but it will be invisible for PKCS#11 interface.

Key set maintenance has to go over side channel for metadata and not
over PKCS#11.


Yep.




The pkcs11 data stored in ldap should represent pkcs11 objects. Other
entries
could reference these objects, eg a zone referencing a key. I don't
think we
should store references to other entries in an pkcs11 object. if you
want this
we probably need another auxiliary objectclass for these pkcs11
entries.

Regarding objectclasses for the pkcs11 objects, what should be the
structural
objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate
objectclass all as
auxiliary, maybe we should have one structural like pkcs11Object
containing
the required attrs like id, label, ...
and a naming attr if it is not one of them

This sounds like a good idea.



+1, although what we refer to as "object" is referred to as "storage
object" in the PKCS#11 spec, so we might name the object class
ipaPkcs11storageObject.

As for the naming attribute, the only PKCS#11 attribute that can't
ever be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId.

do you mean to use this attributename or to use its values. I'd prefer
to make the schema independent of other definitions if possible, so I
thought of something like pkcs11objectId, which can have the same syntax
as ipaUniqueid and use the same semantics.



I meant ipaUniqueId the attribute, but I'm fine with anything else 
(pkcs11UniqueId perhaps? to avoid confusion with pkcs11Id)


--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 10:17 AM, Jan Cholasta wrote:

On 26.2.2014 17:37, Petr Spacek wrote:

On 26.2.2014 15:20, Ludwig Krispenz wrote:
I was talking about 'layer of indirection' previously. I'm digging 
into
details and it seems like a good idea to imitate what DNS 
registrars do
- use concept of key sets. It means that keys are not linked to a 
zone

one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a 
key

set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies
for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to 
keyset

called 'setA'
- zone objects: idnsname=example.net,cn=dns and
idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key
generated
by OpenDNSSEC? Are you suggesting having a separate slot/token for 
each
keyset? I would like to keep the number of tokens low, because 
there are

applications which go slot by slot, token by token when searching for
objects (e.g. BIND and OpenSSH) and that might generate a lot of
unnecessary
traffic if the number of slots/tokens is high.

Okay, then we can store all DNSSEC keys in one slot and use "key sets"
only for administrative purposes (i.e. pairing zone <=> keys in BIND)
but it will be invisible for PKCS#11 interface.

Key set maintenance has to go over side channel for metadata and not
over PKCS#11.


Yep.




The pkcs11 data stored in ldap should represent pkcs11 objects. Other
entries
could reference these objects, eg a zone referencing a key. I don't
think we
should store references to other entries in an pkcs11 object. if you
want this
we probably need another auxiliary objectclass for these pkcs11 
entries.


Regarding objectclasses for the pkcs11 objects, what should be the
structural
objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate
objectclass all as
auxiliary, maybe we should have one structural like pkcs11Object
containing
the required attrs like id, label, ...
and a naming attr if it is not one of them

This sounds like a good idea.



+1, although what we refer to as "object" is referred to as "storage 
object" in the PKCS#11 spec, so we might name the object class 
ipaPkcs11storageObject.


As for the naming attribute, the only PKCS#11 attribute that can't 
ever be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId.
do you mean to use this attributename or to use its values. I'd prefer 
to make the schema independent of other definitions if possible, so I 
thought of something like pkcs11objectId, which can have the same syntax 
as ipaUniqueid and use the same semantics.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified


On Thu, 27 Feb 2014, Martin Kosek wrote:

On 02/26/2014 05:03 PM, Alexander Bokovoy wrote:

On Wed, 26 Feb 2014, Martin Kosek wrote:

On 02/25/2014 06:56 PM, Alexander Bokovoy wrote:

Hi,

Simple patch to fix KeyError as --pkey-only causes no attributes to be
returned and trustdomain_find.post_callback checked them
unconditionally.


https://fedorahosted.org/freeipa/ticket/4196


Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.:

   def post_callback(self, ldap, entries, truncated, *args, **options):
   if not options.get('pkey_only', False):
   trust_dn = self.obj.get_dn(args[0], trust_type=u'ad')
   trust_entry = ldap.get_entry(trust_dn)
   ...

It seems to me that your way we still do one unnecessary LDAP search which is
never used. With pkey_only we should not be filling anything in post_callback
at all if it is not affecting the pkey.

Right, new patch attached.



It still crashes:

[Thu Feb 27 04:55:51.245147 2014] [:error] [pid 3479] Traceback (most recent
call last):
[Thu Feb 27 04:55:51.245149 2014] [:error] [pid 3479]   File
"/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", line 333,
in wsgi_execute
[Thu Feb 27 04:55:51.245152 2014] [:error] [pid 3479] result =
self.Command[name](*args, **options)
[Thu Feb 27 04:55:51.245155 2014] [:error] [pid 3479]   File
"/usr/lib/python2.7/site-packages/ipalib/  frontend.py", line 447, in __call__
[Thu Feb 27 04:55:51.245157 2014] [:error] [pid 3479] 
self.validate_output(ret)
[Thu Feb 27 04:55:51.245159 2014] [:error] [pid 3479]   File
"/usr/lib/python2.7/site-packages/ipalib/  frontend.py", line 947, in
validate_output
[Thu Feb 27 04:55:51.245162 2014] [:error] [pid 3479] nice, o.name, o.type,
type(value), value)
[Thu Feb 27 04:55:51.245164 2014] [:error] [pid 3479] TypeError:
trustdomain_find.validate_output():
[Thu Feb 27 04:55:51.245167 2014] [:error] [pid 3479]   output['truncated']:
need ; got


You need to "return truncated", not just "return". When this is changed, patch
works as expected.

Yep, thanks!

New patch attached.

--
/ Alexander Bokovoy
>From 78f01ada3f1cce43df7bfcc3647747e600d39c2f Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Wed, 26 Feb 2014 17:59:05 +0200
Subject: [PATCH 7/7] trustdomain_find: make sure we skip short entries when 
 --pkey-only is specified

With --pkey-only only primary key is returned. It makes no sense to check and
replace boolean values then.

https://fedorahosted.org/freeipa/ticket/4196
---
 ipalib/plugins/trust.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 0b6db27..bd71253 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -1191,6 +1191,8 @@ class trustdomain_find(LDAPSearch):
 return (filters, base_dn, ldap.SCOPE_SUBTREE)
 
 def post_callback(self, ldap, entries, truncated, *args, **options):
+if options.get('pkey_only', False):
+return truncated
 trust_dn = self.obj.get_dn(args[0], trust_type=u'ad')
 trust_entry = ldap.get_entry(trust_dn)
 for entry in entries:
-- 
1.8.3.1

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified

On 02/26/2014 05:03 PM, Alexander Bokovoy wrote:
> On Wed, 26 Feb 2014, Martin Kosek wrote:
>> On 02/25/2014 06:56 PM, Alexander Bokovoy wrote:
>>> Hi,
>>>
>>> Simple patch to fix KeyError as --pkey-only causes no attributes to be
>>> returned and trustdomain_find.post_callback checked them
>>> unconditionally.
>>>
>>>
>>> https://fedorahosted.org/freeipa/ticket/4196
>>
>> Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.:
>>
>>def post_callback(self, ldap, entries, truncated, *args, **options):
>>if not options.get('pkey_only', False):
>>trust_dn = self.obj.get_dn(args[0], trust_type=u'ad')
>>trust_entry = ldap.get_entry(trust_dn)
>>...
>>
>> It seems to me that your way we still do one unnecessary LDAP search which is
>> never used. With pkey_only we should not be filling anything in post_callback
>> at all if it is not affecting the pkey.
> Right, new patch attached.
> 

It still crashes:

[Thu Feb 27 04:55:51.245147 2014] [:error] [pid 3479] Traceback (most recent
call last):
[Thu Feb 27 04:55:51.245149 2014] [:error] [pid 3479]   File
"/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", line 333,
in wsgi_execute
[Thu Feb 27 04:55:51.245152 2014] [:error] [pid 3479] result =
self.Command[name](*args, **options)
[Thu Feb 27 04:55:51.245155 2014] [:error] [pid 3479]   File
"/usr/lib/python2.7/site-packages/ipalib/  frontend.py", line 447, in __call__
[Thu Feb 27 04:55:51.245157 2014] [:error] [pid 3479] 
self.validate_output(ret)
[Thu Feb 27 04:55:51.245159 2014] [:error] [pid 3479]   File
"/usr/lib/python2.7/site-packages/ipalib/  frontend.py", line 947, in
validate_output
[Thu Feb 27 04:55:51.245162 2014] [:error] [pid 3479] nice, o.name, o.type,
type(value), value)
[Thu Feb 27 04:55:51.245164 2014] [:error] [pid 3479] TypeError:
trustdomain_find.validate_output():
[Thu Feb 27 04:55:51.245167 2014] [:error] [pid 3479]   output['truncated']:
need ; got


You need to "return truncated", not just "return". When this is changed, patch
works as expected.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in batch_error dialog

On 02/26/2014 04:55 PM, Adam Misnyovszki wrote:

- Original Message -

From: "Petr Vobornik" 
To: "freeipa-devel" 
Sent: Tuesday, February 25, 2014 2:19:21 PM
Subject: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in   
batch_error dialog

Dialog loses focus when the links are clicked making the dialog
uncontrollable by keyboard. This patch focuses the link again after
expanding/collapsing the error list. Thus keeping the focus in a dialog

https://fedorahosted.org/freeipa/ticket/4097
--
Petr Vobornik

ACK

works fine on FF26, 27, GC33

Pushed to master: 61770269d436daa4152c5bb949499497320b2aee

--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 0156] trusts: Remove usage of deprecated LDAP API

2014-02-27 Thread Tomas Babej

Hi,

Remove a reference to the old deprecated LDAP API invoked by
the usage of trust_add method.

https://fedorahosted.org/freeipa/ticket/4204

-- 
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 


>From ee59e86f5ee91da97de0484fdcc9b40590844f76 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 27 Feb 2014 10:33:50 +0100
Subject: [PATCH] trusts: Remove usage of deprecated LDAP API

Remove a reference to the old deprecated LDAP API invoked by
the usage of trust_add method.

https://fedorahosted.org/freeipa/ticket/4204
---
 ipaserver/dcerpc.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index 5cc168be4717bf40d5ae31532828488e3a3a819e..c3ae00ef3d089d3617809b4cc81153e0704890b7 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -1102,9 +1102,9 @@ class TrustDomainJoins(object):
 
 realm_domains = self.api.Command.realmdomains_show()['result']
 # Use realmdomains' modification timestamp to judge records last update time
-(dn, entry_attrs) = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp'])
+entry = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp'])
 # Convert the timestamp to Windows 64-bit timestamp format
-trust_timestamp = long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14], "%Y%m%d%H%M%S"))*1e7+1164447360)
+trust_timestamp = long(time.mktime(time.strptime(entry['modifytimestamp'][0][:14], "%Y%m%d%H%M%S"))*1e7+1164447360)
 
 for dom in realm_domains['associateddomain']:
 ftinfo = dict()
-- 
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


On 26.2.2014 17:37, Petr Spacek wrote:

On 26.2.2014 15:20, Ludwig Krispenz wrote:

I was talking about 'layer of indirection' previously. I'm digging into
details and it seems like a good idea to imitate what DNS registrars do
- use concept of key sets. It means that keys are not linked to a zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies
for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and
idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key
generated
by OpenDNSSEC? Are you suggesting having a separate slot/token for each
keyset? I would like to keep the number of tokens low, because there are
applications which go slot by slot, token by token when searching for
objects (e.g. BIND and OpenSSH) and that might generate a lot of
unnecessary
traffic if the number of slots/tokens is high.

Okay, then we can store all DNSSEC keys in one slot and use "key sets"
only for administrative purposes (i.e. pairing zone <=> keys in BIND)
but it will be invisible for PKCS#11 interface.

Key set maintenance has to go over side channel for metadata and not
over PKCS#11.


Yep.




The pkcs11 data stored in ldap should represent pkcs11 objects. Other
entries
could reference these objects, eg a zone referencing a key. I don't
think we
should store references to other entries in an pkcs11 object. if you
want this
we probably need another auxiliary objectclass for these pkcs11 entries.

Regarding objectclasses for the pkcs11 objects, what should be the
structural
objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate
objectclass all as
auxiliary, maybe we should have one structural like pkcs11Object
containing
the required attrs like id, label, ...
and a naming attr if it is not one of them

This sounds like a good idea.



+1, although what we refer to as "object" is referred to as "storage 
object" in the PKCS#11 spec, so we might name the object class 
ipaPkcs11storageObject.


As for the naming attribute, the only PKCS#11 attribute that can't ever 
be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId.


--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA 3.4 -> 4.0