Java Reference
In-Depth Information
As we mentioned previously, identity can be established by the location or origin of
the software artifact or by cryptographic measures using digital certificates. Especially
for the latter approach, the software provider generally needs to make the code avail-
able in such a way that you can establish the needed credentials. When you have
identity established, you need to define the permissions that code should have. For
OSG
i, this is the responsibility of whoever is managing the framework, which can be a
gateway operator, a server administrator, or even an end user. As a consequence, per-
mission management should be kept as simple as possible. Last but not least, secu-
rity must be built into the code itself. You have to think about internal security
checks to prevent external code from performing undesired operations and also how
to limit privileges so external code can perform potentially sensitive operations in a
safe way.
Assuming you're able to develop your code with all the security checks in the right
place, define a reasonably policy to manage permissions, and sign it using a trusted
certificate for establishing identity, is all the work worth it?
Clearly, it depends on your specific situation. In some cases, it's not within the
scope of your application. Either the performance impact is too great or the develop-
ment costs are too high. Often, these issues serve as the determining factor for creat-
ing security-enabled applications. This is compounded by the fact that if code isn't
designed
to be usable in security-enabled environments, it's unlikely to happen by acci-
dent. This results in a catch-22 type of situation, where the difficulty associated with
creating secure code results in security being ignored, which makes it next to impossi-
ble to use such code with security enabled, thus further raising the barriers for decid-
ing to develop with security in mind in the first place.
All hope isn't lost. In the remainder of this chapter, we'll show you that taking
advantage of the security capabilities of the
OSG
i framework needn't be too difficult.
In the next section, we'll start by taking a high-level view of Java and
OSG
i security.
14.2
Security: just do it
So you want to secure your
OSG
i-based application. Great—but where do you start?
Let's begin at the beginning and look at the Java security architecture and its permis-
sion model, on which the
OSG
i security model is based.
14.2.1
Java and OSGi security
It's important to understand the Java security architecture; but to keep this chapter
tightly scoped, we'll introduce only the parts needed to understand the remainder of
the chapter. Welcome to Java security boot camp!
The Java security architecture is fundamentally about the assignment of
java.security.Permission
subclass objects to code. Specific permissions allow
access to specific, sensitive operations, such as file system or network socket access.
How do you grant
Permission
objects to code? The Java security architecture is based
on the two fundamental concepts of domain- and role-based security:
