November 2011 - Pki-devel - Dogtag PKI List Archives

[PATCH] Fix Basic auth handling for passwords containing a colon
by Joshua Roys 06 Feb '12

06 Feb '12

Hello, Attached is a patch to fix the parsing of HTTP Basic auth. Thanks, Joshua Roys

2 2

[PATCH] 0015-Removal-of-unused-private-methods
by Adam Young 21 Dec '11

21 Dec '11

3 7

Request to enable nightly builds of 'ipa-pki-theme' and 'pki-core' on Fedora 16 and Fedora 17 (rawhide)
by Matthew Harmsen 13 Dec '11

13 Dec '11

To satisfy the PKI TRAC ticket https://fedorahosted.org/pki/ticket/61 'pki-ca in ipa-devel has not been built for Fedora 16 and rawhide', please create nightly builds of the following components on Fedora 16 and Fedora 17 (rawhide) for use by FreeIPA: * dogtag-pki-theme o dogtag-pki-common-theme o dogtag-pki-ca-theme o dogtag-pki-kra-theme o dogtag-pki-ocsp-theme o dogtag-pki-ra-theme o dogtag-pki-tks-theme o dogtag-pki-tps-theme o dogtag-pki-console-theme * pki-core o pki-setup o pki-symkey o pki-native-tools o pki-util o pki-util-javadoc o pki-java-tools o pki-java-tools-javadoc o pki-common o pki-common-javadoc o pki-selinux o pki-ca o pki-silent For 'stability' purposes, please point these nightly builds to use the following branch from the new PKI 'git' repo (until notified otherwise): * git clone -b DOGTAG_9_BRANCH git://git.fedorahosted.org/git/pki.git Thanks, -- Matt

3 4

[PATCH] 0017-call-statics-statically
by Adam Young 06 Dec '11

06 Dec '11

2 6

[PATCH] 0019-PKISilent-type-safety-changes
by Adam Young 06 Dec '11

06 Dec '11

Tested by running ipa-server-install, which calls pkisilent.

2 4

CMake 'JNI' macro question . . .
by Matthew Harmsen 05 Dec '11

05 Dec '11

Andreas, I would like to request your assistance on the following 'CMake' issue requested by Adam: * https://fedorahosted.org/pki/ticket/9 Basically, on Fedora 16 and later, the default location of Java Native Interface (JNI) jar files was changed to reside under '/usr/lib/java' for 32-bit platforms, and '/usr/lib64/java' for 64-bit platforms. Per the TRAC ticket, I made a change in the spec files to handle this via the 'jpackage-utils' RPM. However, I do not know if 'CMake' can change the 'JAVA_LIB_INSTALL_DIR' macro located in the 'pki/cmake/Modules/DefineInstallationPaths.cmake' file to rely on the '%{_jnidir}' macro of 'jpackage-utils' stored in the '/etc/rpm/macros.jpackage', or if there is a different way of handling this where the following logic comes into play: * '/usr/lib/java' on RHEL 6 and earlier (32-bit AND 64-bit platforms) * '/usr/lib/java' on Fedora 15 and earlier (32-bit AND 64-bit platforms) * '/usr/lib/java' on Fedora 16 and later (32-bit platforms) * '/usr/lib/java' on Fedora 16 and later (using a 32-bit JVM on 64-bit platforms) o I am fairly confident that this case may actually REQUIRE a compiler override, as it does not look as if 'jpackage-utils' computes its '%{_jnidir}' macro based upon the 'JVM' architecture being utilized, but rather the '%{_libdir}' macro based upon the operating system architecture located in the appropriate '/usr/lib/rpm/platform/<platform>/macros' file * '/usr/lib64/java' on Fedora 16 and later (64-bit platforms) Your assistance on this matter is greatly appreciated. Eventually, do you think that we may want the appropriate logic added to the '/etc/rpm/macros.cmake' file? Thanks, -- Matt

3 5

[PATCH] 0014-Adjust-classpath-for-F16
by Adam Young 02 Dec '11

02 Dec '11

2 2

[PATCH] 0013-unnecessary-block-removal
by Adam Young 02 Dec '11

02 Dec '11

1 1

Tomcat Realms and Directory Server
by Adam Young 02 Dec '11

02 Dec '11

One issue I have been looking at recently is how to integrate PKI and IPA at the auth level while keeping a clean separation. We can extract the authentication from the servlet code, so it is purely a matter of configuring the Tomcat instance Realm. I wrote up a Proof of concept for just doing pure LDAP using simple bind, which is not a bad starting point. http://adam.younglogic.com/2011/11/tomcat-simple-ipa/ We want to continue this approach, but use a more secure authentication method. We won't be using basic auth, and we won't be using simple bind. There are two forms of authentication we want to support: Client Certificates and Kerberos. Certificates will work as they do now, and Kerberos will be for passing through user credentials from IPA, through HTTP to CS. In both cases, the data that backs it will be stored in the DS instance. Tomcat has a class classed a CombinedRealm: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm That might support stacking Certificate and Kerberos auth on top of each other. The Realm will then delegate to LDAP for extracting the Roles. http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm Kerberos is typically done using a JAAS Realm. I have to admit I don't really like the fact that we have to modify the JVM startup to do so, it is not really that big of a deal. I was also not a fan of setting the Realm up as a single service ticket until Simo informed me that the Browser NEGOTIATE mechanism assumes that the Service ticket is going to be Named HTTP. This means that for Proxied implementations, to include IPA, we will have to share the Service Principal Identity with the Apache HTTPD server. http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm However, once you start digging in, you will find that the solutions are suboptimal. It turns out that the Negotiate auth-method has only very recently been supported, and that is only on Tomcat7. The best resource I have found on the options for a custom realm is here: http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos and the most likely option http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule We really want a mix of the KRB5Login Module and the JNDIRealm. That seems to be what is described here: http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with Tomcat-7. I suspect that the CombinedRealm approach will not support falling back from one auth-method to another: I've been looking and have not see it specified that you can put multiple auth-method entries inside a login-config in the web.xml. Ideally, we would attempt a Certificate based authentication first, and then fall back to Negotiate. However, we can say that a given deployment is going to be either Kerberos or Client Certificate, and swap out the configuration at the Tomcat level. I don't like that nearly as much. The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback talks about how to do Client Cert with a fallback to Form based authentication. We'd want to do Client Cert with a fallback to Krb5. This is using what is called a Valve. In Tomcat 6 and 7 valves have been deprecated in favor of Filters. The general approach is the same. I'd like to keep the idea of the Realm as the primary approach. If we do have to build a custom Realm, and I suspect that we will, we might want to spin it off into its own package, or submit it for Inclusion in Tomcat 7 upstream. It seems that the PKI approach has been to Bind as Directory Manager. What I would like to target moving forward is that the Bind is done as the user making the web request. For managed operations that require a higher level of authentication, we use the concept of queues like we do now. The threads that manage those queue will use a Principal with a higher level of authorization: not "Directory Manger", but perhaps "CA Manager" which is a user we create that manages the CA subtree in the Directory server. For a Dogtag deployment without IPA, the CA Manger would have write privileged on the Identity subtree. For integrated deployments, IPA would have its own principal "IPA Manager" that would not have read or write capabilities in the CA Subtree. DRM, TKS and other subsytems would in turn also get their own Manager users, and they would only have permissions to manage their own trees: we will need to clear up which gets read and write permissions on which other subtrees. Directory Manager would be limited to performing operations that effect the entire DS instance: Setup and Replication. The Directory Manager, CA Manager, IPA manager users should be binding with a certificate or a keytab, not with a cleartext password.

2 2

Question about nightly builds of 'pki-ca' for 'ipa-devel' in Fedora 16 and Rawhide . . .
by Matthew Harmsen 30 Nov '11

30 Nov '11

Before I file two release engineering tickets (one for F16 and one for F17 (rawhide)), I have a couple of questions regarding the following ticket: * https://fedorahosted.org/pki/ticket/61 As we are in the midst of moving source code from an 'svn' repo to a 'git' repo, and making potentially radical changes to the tip, should I: 1. Specify using an 'svn' repo or a 'git' repo for generating these nightly builds? 2. Specify the 'trunk', or 'DOGTAG_9_BRANCH' (the last 'stable' Dogtag source code that was released on Fedora 15, 16, and 17)? -- Matt

3 3