Security is critical for the success of PageBoxes because:
- Constellation are cross-organization infrastructures. A participant must be able to trust other participants.
- Presentations are deployed on a large number of PageBoxes. In case of error the PageBox host must be able to identify and
notify the publisher. The publisher must be able to diagnose errors occurred on a deployed presentation.
- PageBox infrastructure should provide a charging service.
The PageBox architecture involves six actors:
- The repository that deploys presentations
- The publisher who publishes presentations
- The administrator who administrates repositories
- The subscriber who subscribes PageBoxes
- The PageBox that hosts presentations
- The customer who uses presentations
The infrastructure is not centralized. It can include many repositories and PageBoxes don't require their availability.
However a repository acts as a hub for a given presentation.
We found some inspiration in
a Publishing and Royalty Model for Networked Documents.
This document was written by Ted Nelson for the Xanadu project, the ancestor of the Web and considers the publication of
It describes three main roles:
- The document publisher, responsible for any disagreeable consequence under law and tort
- The service provider who agrees to send the document to the customer
- The customer who agrees to pay the document at a rate specified by the publisher and a delivery fee to the service
In case of PageBox infrastructure, the same rule can apply with four roles:
- The presentation publisher, responsible for any disagreeable consequence under law and tort
- The repository, responsible for the deployment of the presentation on PageBox hosts
- The PageBox host, who agrees to run the presentation
- The customer who conceptually agrees to pay for the presentation
The case is more complex because different actors can receive the payment. We consider here three common scenarios:
The shopping basket presentation
The presentation bills the customer and get the money. The presentation publisher pays the provider(s), the PageBox hosts
and the repositories.
The provider typically:
- Maintains the inventory and provides availability web services
- Is responsible for the good delivery
- Charges the presentation publisher
The tributary presentation
The provider bills the customer and get the money. It pays the presentation publisher.
The presentation publisher pays the PageBox hosts and the repositories.
The advertised presentation
The advertiser pays the presentation publisher. The presentation publisher pays the PageBox hosts and the repositories.
The rule is:
- The repositories and PageBox hosts charge the publisher. The publisher, the repositories and the PageBost host must be
- The publisher is paid by the customer, the provider or the advertiser. The mechanism is implemented by the presentation
outside the scope of PageBox.
The repository (PublisherServer) uses HTTPS with public key authentication.
The SSL/TLS handshaking is:
The client can check the server certificate and the server can check the client certificate.
Partners cannot repudiate their messages because only the certificate owner has the private key
allowing to sign the request.
|1.||Client hello||----->|| |
|2.|| ||<-----||Server hello|
|4.|| ||<-----||Certificate request|
|5.|| ||<-----||Server key exchange (Optional)|
|6.|| ||<-----||Server hello done|
|8.||Client key exchange||----->|| |
|9.||Certificate verify (Optional)||----->|| |
|10.||Change cipher spec||----->|| |
|12.|| ||<-----||Change cipher spec|
|14.|| ||<-----||Encrypted data|
The handshaking above implies that the server requests the client certificate.
This capability is described in Servlet specification but is not always implemented in application servers.
Therefore in Publisher version 1.0.5, we use an Apache front-end server with mod_ssl:
PublisherServer doesn't require a front-end server. In secured mode, given an HttpServletRequest request, it requires:
- The publisher publishes a presentation with PublisherClient.
- The administrator uses a browser to administrate the repository.
- PageBoxes download the presentation.
- Apache checks the validity of the client certificate and forwards the requests to
PublisherServer using the ajp13 protocol.
- PublisherServer retrieves the client certificate.
- request.isSecure() to be true
- request.getScheme() to be https
- javax.servlet.request.X509Certificate attribute to be set
A publisher or administrator should only use one certificate, whatever browser or application that she/he uses.
It is difficult but not impossible to do so. We describe below a solution. It is possibly not the only one.
We also didn't test all browser versions.
- We found Netscape 6.0 buggy.
- Opera 5.11 was very convenient for our tests as it allows setting the algorithms but it doesn't support exporting
- Netscape 4.5/4.7 and Internet Explorer 5/5.5
allow exporting certificates and private keys but Java 2 doesn't understand certificates exported by Internet Explorer
Therefore use Netscape 4.77, which uses a 128 bits encryption, at least to require certificates.
Next export the certificate in PKCS#12 format. Then you can import it in IE 5 and use it in Java.
See the Mindprod site for more information.
A certificate is valid for Apache/mod_ssl if it was signed by an authority that the repository trusts.
PublisherClient checks that the publisher has registered its certificate.
The registration is implemented in a form where the publisher provides information such as her/his credit card number or
Not implemented in version 1.0.5
- The repository defines how much it charges the publishers and pays the PageBox hosts.
Criteria can be deployment cost, presentation size x time, number of presentation calls...
It makes criterion available on HTML pages and XML files.
- When it subscribes, the PageBox host agrees on the fee.
- The publisher agrees on the fee when she/he publishes.
- PageBoxes report presentation use to the repository.
©2001-2004 Alexis Grandemange