Request to build the following PKI components on Fedora 15, Fedora 16, and Fedora 17 (Rawhide) . . .
by Matthew Harmsen
Please build the following components on Fedora 15, Fedora 16, and
Fedora 17 (rawhide) in Koji . . .
* dogtag-pki-theme-9.0.9-1.fc15.src.rpm (dogtag-pki-theme)
* pki-core-9.0.15-1.fc15.src.rpm (pki-core)
* pki-console-9.0.5-1.fc15.src.rpm (pki-console)
* pki-kra-9.0.8-1.fc15.src.rpm (pki-kra)
* pki-ocsp-9.0.7-1.fc15.src.rpm (pki-ocsp)
* pki-tks-9.0.7-1.fc15.src.rpm (pki-tks)
* pki-ra-9.0.4-1.fc15.src.rpm (pki-ra)
* pki-tps-9.0.7-1.fc15.src.rpm (pki-tps)
* dogtag-pki-9.0.0-7.fc15.src.rpm (dogtag-pki)
All changes have been checked-in, and the official tarballs (for all
three platforms) have been published to:
* http://pki.fedoraproject.org/pki/sources/dogtag-pki-theme/dogtag-pki-them...
(dogtag-pki-theme)
* http://pki.fedoraproject.org/pki/sources/pki-core/pki-core-9.0.15.tar.gz
(pki-core)
* http://pki.fedoraproject.org/pki/sources/pki-console/pki-console-9.0.5.ta...
(pki-console)
* http://pki.fedoraproject.org/pki/sources/pki-kra/pki-kra-9.0.8.tar.gz
(pki-kra)
* http://pki.fedoraproject.org/pki/sources/pki-ocsp/pki-ocsp-9.0.7.tar.gz
(pki-ocsp)
* http://pki.fedoraproject.org/pki/sources/pki-tks/pki-tks-9.0.7.tar.gz
(pki-tks)
* http://pki.fedoraproject.org/pki/sources/pki-ra/pki-ra-9.0.4.tar.gz
(pki-ra)
* http://pki.fedoraproject.org/pki/sources/pki-tps/pki-tps-9.0.7.tar.gz
(pki-tps)
* N/A
(dogtag-pki)
The official spec files (for all three platforms) are located at:
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/dogtag-pki...
(dogtag-pki-theme)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-core.spec
(pki-core)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-consol...
(pki-console)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-kra.spec
(pki-kra)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-ocsp.spec
(pki-ocsp)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-ra.spec
(pki-ra)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-tks.spec
(pki-tks)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/pki-tps.spec
(pki-tps)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/dogtag-pki...
(dogtag-pki)
To build the specified components, please import the following into the
buildroot:
* Fedora 15
o jss-4.2.6-20.el15 (pki-core, pki-console, pki-kra,
pki-ocsp, pki-tks)
o osutil-2.0.2-1.el15 (pki-core)
o tomcatjss-6.0.2-1.el15 (pki-core)
* Fedora 16
o jss-4.2.6-20.el16 (pki-core, pki-console, pki-kra,
pki-ocsp, pki-tks)
o osutil-2.0.2-1.el16 (pki-core)
o tomcatjss-6.0.2-1.el16 (pki-core)
* Fedora 17
o jss-4.2.6-20.el17 (pki-core, pki-console, pki-kra,
pki-ocsp, pki-tks)
o osutil-2.0.2-1.el17 (pki-core)
o tomcatjss-6.0.2-1.el17 (pki-core)
Thanks,
-- Matt
13 years, 1 month
Request to build the following PKI components on Fedora 15, Fedora 16, and Fedora 17 (Rawhide) . . .
by Matthew Harmsen
Fixes have been made to allow Dogtag 9.0 to build successfully on Fedora 17!
Please build the following components on Fedora 15, Fedora 16, and
Fedora 17 (rawhide) in Koji . . .
* pki-core-9.0.16-1.fc[15,16,17].src.rpm (pki-core)
* pki-kra-9.0.9-1.fc[15,16,17].src.rpm (pki-kra)
* pki-ocsp-9.0.8-1.fc[15,16,17].src.rpm (pki-ocsp)
* pki-tks-9.0.8-1.fc[15,16,17].src.rpm (pki-tks)
* dogtag-pki-9.0.0-8.fc[15,16,17].src.rpm (dogtag-pki)
and please build the following components on Fedora 17 (rawhide) in Koji
. . .
* pki-ra-9.0.4-1.fc17.src.rpm (pki-ra)
* pki-tps-9.0.7-1.fc17.src.rpm (pki-tps)
All changes have been checked-in, and the official tarballs (for all
three platforms) have been published to:
* http://pki.fedoraproject.org/pki/sources/pki-core/pki-core-9.0.16.tar.gz
(pki-core)
* http://pki.fedoraproject.org/pki/sources/pki-kra/pki-kra-9.0.9.tar.gz
(pki-kra)
* http://pki.fedoraproject.org/pki/sources/pki-ocsp/pki-ocsp-9.0.8.tar.gz
(pki-ocsp)
* http://pki.fedoraproject.org/pki/sources/pki-tks/pki-tks-9.0.8.tar.gz
(pki-tks)
* N/A
(dogtag-pki)
likewise, the official tarballs for the additional Fedora 17 (rawhide)
builds are available at:
* http://pki.fedoraproject.org/pki/sources/pki-ra/pki-ra-9.0.4.tar.gz
(pki-ra)
* http://pki.fedoraproject.org/pki/sources/pki-tps/pki-tps-9.0.7.tar.gz
(pki-tps)
The official spec files (for all three platforms) are located at:
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki...
(pki-core)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki...
(pki-kra)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki...
(pki-ocsp)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/pki...
(pki-tks)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA/dog...
(dogtag-pki)
likewise, the official spec files for the additional Fedora 17 (rawhide)
builds are available at:
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA-17/...
(pki-ra)
* https://alpha.dsdev.sjc.redhat.com/home/mharmsen/kwright/SPECS/FEDORA-17/...
(pki-tps)
Thanks,
-- Matt
13 years, 1 month
Client Authentication
by Adam Young
Ade,
Your ealier emali discussed the renegotiation challenge based on the
Profiles.
http://pki.fedoraproject.org/wiki/REST#Profiles
For the case where a user points a browser (say and Ajax request) at
/pki/profiles lets say that we have two cases: one where the user is
authenticated and one where they are not. In both cases, they get back
a collection, but in the case of unauthenticated it will have
significantly fewer entries.
In this case, we would want the Java equivalent of mod_nss:
NSS_VerifyCLient: Optional
I'm guessing this a tomcatjss setting.
In this case, if the user has the certificate, they can present it, but
if they don't, the operation will complete. I think this is what we
want. We always ask for the certificate, but we say it is OK if you
don't have it, you just don't get the data.
In the case where the user is asking for an object, say an actual
profile, and they don't have sufficient privs, they get back a hard and
fast error: probably 403.2
http://en.wikipedia.org/wiki/HTTP_403
For something like CSRs, we probably want to restrict access to agents.
In that case, if an unauthenticated user, or one without appropriate
privs, attempts to access that URL, they also get a 403.2.
I don't know how this works in with the renegotiate, but I am guessing
that every time the user without a certificate hits an "Optional" page
they will be asked for their cert. This might be chatty. No idea.
So in general, we tag the URLS either
NSS_VerifyClient: Require if they must be authenticated to use them
NSS_VerifyClient: Optional if they see different results based on
authentication or not
NSS_VerifyClient: None if they can view them unauthenticated and see the
same results as everyone else
IN the pki/WEB-INF/web.xml, this probably maps to something like this:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Resource</web-resource-name>
<url-pattern>*/*/profile*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*anonymous*</role-name>
<role-name>*agent*</role-name>
</auth-constraint>
</security-constraint>
I'm guessing that we want to specify a role for anonymous as opposed to
no role.
<web-app>
...
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Tomcat Manager Application</realm-name>
<realm-name>PKICA</realm-name>
</login-config>
...
</web-app>
the PKICA Realm would be defined at the server level, in
conf/server.xml. Something like:
<Realm className="com.netscape.catalina.realm.LDAPCertRealm"
connectionURL="ldaps://localhost:8389"
userPattern="uid={0},ou=people,dc=mycompany,dc=com"
roleBase="ou=groups,dc=mycompany,dc=com"
roleName="cn"
roleSearch="(uniqueMember={0})"
/>
There is a class that almost does what we want.
*org.apache.catalina.realm.JNDIRealm*.
I suspect we can subclass it. It has two ways of doing the auth : Bind
mode and Comparison mode. It might be possible to add a Client Cert
mode in a subclass. docs are here:
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JNDIRealm
13 years, 1 month
Choosing a REST implementation
by Adam Young
As we close in on the decision about REST, I'd like to mention one thing
that Ade and I have been looking into: which REST implementation to choose.
It seems like the world has settled in on JAX-B as the API of choice.
This makes things as little easier for us, as it means we can program to
a standard API and swap out the libraries. I've done what I call a
Spike ( something less than a proof-of-concept, more like poking a
hole in the ground to see if something comes out) using the reference
implementation: Jersey. With this I can do:
curl -H "accept: application/json" -H "Accept: applicaton/json"
http://$IPASERVER:8080/PKIREST/pki/certificates/2
And get back:
{"algorithmID":"RSA","issuer":"Fedora PKA Server
Cert","serialNumber":"2","version":"0"}
as well as
curl -H "accept: application/xml" -H "Accept: applicaton/json"
http://$IPASERVER:8080/PKIREST/pki/certificates
Which gets:
<?xml version="1.0" encoding="UTF-8"
standalone="yes"?><certificates><certificate><algorithmID>RSA</algorithmID><issuer>Fedora
PKA Server
Cert</issuer><serialNumber>2</serialNumber><version>0</version></certificate><certificate><algorithmID>RSA</algorithmID><issuer>Fedora
PKA
CA</issuer><serialNumber>1</serialNumber><version>0</version></certificate></certificates>
So we have a library and an approach that can handle both XML and JSON
without much fuss.
Note that this is just a Plain Ole Java Object (POJO) that is a place
holder for a real certificate and not anything that ties in with our
APIs. As I said, a spike.
The other REST implementations I've checked out are RESTlet and
RESTeasy. Of them, RESTeasy is closer to home, as it is supported by
the JBoss team, and is the JBoss REST Implementation of choice. Both of
them are complicated enough that it is not immediately clear how to go
about integrating them into a pre-existing Serlvet app. I'm sure it is
not much different than the Jersey code base.
The questions then are: does the Jersey implementation do everything
that we foresee needing and how hard would it be to package.
I'll answer the packaging question first, as it is the easier one.
In order to productize the Jersey implementation for shipping with PKI
I'd have to get the source for Jersey and make an RPM out of it:
someone on the JPackage team has done this in the past, and it shouldn't
be hard to move it forward to the latest Jersey implementation.
The Jersey implementation from the Oracle site provides:
asm-3.1.jar jackson-xc-1.8.3.jar
jersey-server-1.9.1.jar
jackson-core-asl-1.8.3.jar jersey-client-1.9.1.jar jettison-1.1.jar
jackson-jaxrs-1.8.3.jar jersey-core-1.9.1.jar jsr311-api-1.1.1.jar
jackson-mapper-asl-1.8.3.jar jersey-json-1.9.1.jar
Most of these are not in Fedora yet. Only jettison.
asm is at an older version(2) but we should be able to get 3 in with a
the name asm3, which is what I think is already going to happen for
Maven support. I suspect it would not be that hard to package the
others and get them into Fedora. The source for all of them is in the
Maven Repo: http://download.java.net/maven/2/com/sun/jersey/ and
converting Maven POMs to Spec files is straightforward enough that it
can be automated.
The other REST implementations are in pretty much the same boat. None
of the mare packaged for Fedora, and most of them pull in quite a few
other packages for Building. Both RESTlet and RESTeasy are fairly
heavy weight to build: they both go beyond providing a library that
interfaces with the Servlet API to providing full Servers, far more than
we would want to support. Lets just say that getting them to build as
RPMs is a task that I would not be willing to take on in support of
PKI. There are a few others out there, but mostly they seem to be
projects that were originally for web services that decided to add
support for REST as well.
So then the question is: Does Jersey does everything we think we need it
to do? The short answer right now is that I don't know, but I suspect
so. REST is basically making Heavy use of the HTTP definition, so
really, the question is does it let us maximize things like redirects,
response codes, renegotiation and authentication. This is the next
stage of investigation, and I'll keep you posted.
13 years, 1 month
POST-a vs. POST-b
by Ade Lee
I was asked today what the difference in the interface doc was between
POST-a and POST-b.
Below is an excerpt from Restful Web Services (in the best practices
chapter) that explains in more detail.
Basically, POST-a is using POST to add a new resource. You must use
POST instead of PUT if the server is responsible for the final URI.
Example, in creating a new request, the server is responsible for
assigning a request_id and hence the link to the uri -- /pki/request/$id
This is a good use of POST (as described in section 8.6.2)
8.6.3 describes the overloaded use of POST - which is as the result of a
submission of a form. This is what I call POST-b - and what some call
POST-p (for POST-processor).
We have tried to reduce the number of cases where POST-b is used. Its
not bad in and of itself, but it makes the interface less clear and less
resource oriented or RESTful. Sometimes we have to use it -- as Jack
specified for OCSP for instance. In the case of CRLs, at this point I
just do not understand how that interface is supposed to work (and am
waiting for Andrew or Christina to tell me).
Hope this helps,
Ade
*********************************************
8.6.2. New Resources: PUT Versus POST
You can expose the creation of new resources through PUT, POST, or both.
But a client can only use PUT to create resources when it can calculate
the final URI of the new resource. In Amazon’s S3 service, the URI path
to a bucket is /{bucket-name}. Since the client chooses the bucket name,
a client can create a bucket by constructing the corresponding URI and
sending a PUT request to it.
On the other hand, the URI to a resource in a typical Rails web service
looks like /{database-table-name}/{database-ID}. The name of the
database table is known in advance, but the ID of the new resource won’t
be known until the corresponding record is saved to the database. To
create a resource, the client must POST to a “factory” resource, located
at /{database-table-name}. The server chooses a URI for the new
resource.
8.6.3. Overloading POST
POST isn’t just for creating new resources and appending to
representations. You can also use it to turn a resource into a tiny
RPC-style message processor. A resource that receives an overloaded POST
request can scan the incoming representation for additional method
information, and carry out any task whatsoever. This gives the resource
a wider vocabulary than one that supports only the uniform interface.
This is how most web applications work. XML-RPC and SOAP/WSDL web
services also run over overloaded POST. I strongly discourage the use of
overloaded POST, because it ruins the uniform interface. If you’re
tempted to expose complex objects or processes through overloaded POST,
try giving the objects or processes their own URIs, and exposing them as
resources. I show several examples of this in Section 8.8” later in this
chapter.
There are two noncontroversial uses for overloaded POST. The first is to
simulate HTTP’s uniform interface for clients like web browsers that
don’t support PUT or DELETE. The second is to work around limits on the
maximum length of a URI. The HTTP standard specifies no limit on how
long a URI can get, but many clients and servers impose their own
limits: Apache won’t respond to requests for URIs longer than 8 KB. If a
client can’t make a GET request to
http://www.example.com/numbers/1111111 because of URI length
restrictions (imagine a million more ones there if you like), it can
make a POST request to http://www.example.com/numbers?_method=GET and
put “1111111” in the entity-body.
If you want to do without PUT and DELETE altogether, it’s entirely
RESTful to expose safe operations on resources through GET, and all
other operations through overloaded POST. Doing this violates my
Resource-Oriented Architecture, but it conforms to the less restrictive
rules of REST. REST says you should use a uniform interface, but it
doesn’t say which one.
If the uniform interface really doesn’t work for you, or it’s not worth
the effort to make it work, then go ahead and overload POST, but don’t
lose the resource-oriented design. Every URI you expose should still be
a resource: something a client might want to link to. A lot of web
applications create new URIs for operations exposed through overloaded
POST. You get URIs like /weblog/myweblog/rebuild-index. It doesn’t make
sense to link to that URI. Instead of putting method information in the
URI, expose overloaded POST on your existing resources
(/weblog/myweblog) and ask for method information in the incoming
representation (method=rebuild-index). This way, /weblog/myweblog still
acts like a resource, albeit one that doesn’t totally conform to the
uniform interface. It responds to GET, PUT, DELETE... and also
“rebuild-index” through overloaded POST. It’s still an object in the
object-oriented sense.
A rule of thumb: if you’re using overloaded POST, and you never expose
GET and POST on the same URI, you’re probably not exposing resources at
all. You’ve probably got an RPC-style service.
13 years, 1 month