Java Reference
In-Depth Information
sandboxes and their restrictions are difficult to get right and often hard to manage.
This is especially true in an environment as dynamic as the
OSG
i framework. To help
with this situation,
OSG
i defines an extensive and powerful security model to ease
security management.
In this chapter, we'll familiarize you with the Java security model and how
OSG
i
uses it to securely deploy and manage applications. You'll learn how to create secure
applications and well-behaved bundles for security-enabled
OSG
i frameworks. Before
we start with that, let's look at some general issues you'll need to consider when trying
to secure your applications.
14.1
To secure or not to secure
Modern applications and software solutions increasingly center around loosely cou-
pled, extensible architectures. Component and service orientation are applied to
almost all areas of application development including distributed systems, ubiquitous
computing, embedded systems, and client-side applications. One of the main drawbacks
of loosely coupled, extensible applications is the potential security issues around exe-
cuting untrusted code. There are two common reasons for running untrusted software:
Permission management is often extremely complicated.
Often, users are left to make
security policy decisions, and they're typically unable to assess the impact of
granting a given permission. Further, because the user is typically using an
application to perform some task, security is largely viewed as an obstacle
because it doesn't contribute to the task at hand.
■
It's inherently tricky to establish meaningful identity of third-party software providers.
It's
often necessary to differentiate between providers or types of providers to prop-
erly grant or deny permissions. Often the origin of the software artifact (where it
came from) is used for this purpose, but techniques like digital signatures are also
needed to ensure that the software hasn't been tampered with. Digital signatures
introduce the complicated process of creating and maintaining certificates and
trust between certificates, which can be onerous for both users and developers.
■
This raises perhaps the biggest issue with securing code: it adds another burden to
development. Even if you don't plan to run with security enabled, your code has to be
aware of security if you want it to be possible for other people to use the code when
security is enabled. Then, to make matters worse, if you decide to enable security, the
fine-grained security checks impose an execution-time performance penalty.
Despite these issues, security isn't something that can or should be ignored,
because plenty of people are willing to take advantage of software vulnerabilities.
What do you need to do? Providing meaningful security management involves three
key aspects:
Establishing identity
■
Establishing policies to manage permissions
■
Performing permission checks and privilege management
■
