There is no silver bullet for security. However, a well-thought-out
security strategy greatly increases the chances of achieving a
secure system. Anyone that says a system is 100% secure is fooling
themselves one hundred percent. In fact, security is much like
a vaccine, as eventually new variants of disease occur that make
the vaccine ineffective. A static security scheme will naturally
deteriorate over time. If security is a wall, the higher it is
the harder it is to overcome; but there is always a way to get
over the wall. Security requires a good strategy, diligence, and
the acceptance of the occasional inconvenience of security enforcement.
The Openwings architecture focuses on zero administration, plug-n-operate
(PLOP) systems. Security is in direct opposition to this, as it
attempts to put barriers in place to make systems more difficult
to access. The trick is to provide ease of use for those who authorized
to use it, while making it very difficult for those who are not
authorized to use it. There is a natural tension between the dynamic
nature of Openwings and the static nature of security models.
Achieving balance between the fundamental tension of security
and ease of use is the goal of the Openwings Security specification.
All security schemes create some barrier to entry--The variance
in schemes is seen in how high and how many barriers there are.
These barriers started with castle walls, moats, and keys; today
there are firewalls, encryption, and certificates.
The Openwings Security Architecture is divided into several areas.
These include Code Installation Security, Code Execution Security,
and Service/Transport Security. Each of these areas addresses
a different aspect of the security problem.
Code Installation Security provides a mechanism to verify
that software installed within a distributed system is supplied
by a trusted source, and to validate the integrity of the software
prior to installation.
Code Execution Security addresses the problem of what
code is allowed to do when it is executing on a platform. This
includes permissions such as access to the file system, network
ports, system devices and other such services. By limiting this
access, the system provides a mechanism by which both trusted
and untrusted mobile code can run within a "sandbox",
within which access to resources may be controlled based on the
level of trust allocated to the code.
Service/Transport Security addresses the problem of securing
access to services, and at which level a given user may perform
actions provided by a service. Additionally, it provides the ability
to apply the concepts of privacy, integrity, and non-repudiation
within a distributed system.
Openwings Security is a large and complex topic. Look at the
Openwings
Security Presentation for a good overview. You may also find
reading the Security
Specification helpful.
The rest of this tutorial trail covers how to install, configure,
and use the secure version of the Openwings reference implementation.
We provide three additional tutorial trails for component developers:
Next: Installing
the Secure Openwings Reference Implementation
