Java Reference
In-Depth Information
In
OSG
i, the signer of a bundle is associated with it. With this association, you can
grant permissions to a bundle based on its signers. For example, you can assign per-
missions to all bundles from a particular company, if the company signs its bundles.
You can also grant permissions to per form operations on bundles signed by specific
principles. These approaches provide a simple yet powerful way to control who can do
what inside your application.
Effectively, bundle signing creates a powerful delegation model. An administrator
can grant a restricted set of permissions to a signer, after which the signer can create
bundles that use those permissions or some subset, without any intervention or com-
munication with the administrator for each particular bundle. To understand how this
all fits together, consider the following scenario.
Assume you have a system that features a set of core bundles (which we'll call the
core domain
) and an arbitrary number of third-party plugin bundles (which we'll call
the
third-party domain
). This means you expect fully trusted bundles and not com-
pletely trusted bundles to exist in your system, but you want to provide a level of isola-
tion between them. Your goal is to create a simple security policy that lets you manage
core and third-party bundle domains without knowing the precise bundles in each set.
We'll delve into the details of doing this next.
CERTIFICATES AND KEYSTORES
To i m p l e m e n t t h e d e s i r e d s e c u r i t y p o l i c y f o r t h i s s c e n a r i o , y o u n e e d t o c r e a t e t w o r o o t
certificates for the core and third-party domains. These root certificates will be used
by the framework to establish a chain of trust for the two domains. With these two cer-
tificates, you can then sign certificates of core and third-party providers with the
appropriate certificate. When they use their individual certificates to sign bundles
they've created, the framework can use the root certificates to establish a chain of
trust and determine to which domain a bundle belongs.
The details of all this are based on Java 2
JAR
file signing, which means the same
tools you use to sign
JAR
files can be used for
OSG
i. To create the needed certificates
and their associated public and private keys, you'll use the
keytool
command pro-
vided by the
JDK
. It can create and manage certificates and keys inside a
keystore
, which
is an encrypted file defined by Java for this purpose. For this scenario, you use
key-
tool
to create two certificates and their associated public/private keys for the core
and third-party domains like this:
keytool -genkey -keystore keys.ks -alias core -storepass foobar \
-keypass barbaz -dname "CN=core,O=baz,C=de"
keytool -genkey -keystore keys.ks -alias third-party \
-storepass foobar -keypass barbaz -dname "CN=third-party,O=baz,C=de"
This creates a keystore called
keys.ks
containing two new key pairs and a certificate
for each pair with aliases of
core
and
third-party
. The keystore is protected by the
password
foobar
, and the keys themselves have the password
barbaz
. The
-dname
switch allows you to specify the distinguished name you use to identify yourself, which
in this case is the
baz
organization in Germany (
de
).
