For a listing of bug fixes and enhancements included in
this release, please visit our bug
database.
This version of Openwings slightly extends the functional
security framework from prior releases. This includes the
code security framework implemented in the container in
release 0.9.2, and the security framework implemented in
1.0. The purpose of the Openwings security implementation
is to allow for authentication, authorization and Role Based
Access Control within the Openwings framework. There are
several goals that we aimed to achieve with our implementation:
- Provide a mechanism to store users, passwords, and roles
within the Openwings framework
- Provide user authentication upon system or process startup
- Provide user authorization for access to services based
on roles
- Isolate these mechanisms from the process as much as
possible by using the connector framework for implementation
- Provide trusted installation of software, based on signed
installation jars
- Provide Audit logging mechanism to log important events
such as Login attempts
The Security Implementation provided with the Openwings
Reference Implementation is not meant to be a complete security
solution for your platform. It is mainly intended to be
a proof of concept, wherein we provide an example of how
to interface with a security provider to achieve the goals
listed above. Thus we show that the Security Service and
an RMI based "secure connector" can be used to
interact with a user/role repository to provide authentication
and role-based access to services. This "secure connector"
could also interface with a certificate store of
some variety to provide encryption for all data transfers;
however, due to export restrictions, the Openwings Reference
Implementation does not include a connector capable of this
type of encryption. We expect to provide controlled download
of the encrypted version when we have the legal export issues
approved.
- This implementation is based upon available standard
Java Security technologies. In particular, we are using
a keystore as the back end of the security service. Future
releases are expected to use upcoming standards such as
the Liberty Project. The user/role repository is provided
by using the Security Service to interact with a Java
KeyStore. This KeyStore stores Username and Password information
as well as providing a mechanism by which Roles may be
signed to ensure they may be trusted.
- Login is based on JAAS login modules to provide an extensible
login model.
- JGSS is used internally so that security providers may
be added.
- The Security Service interface may be re-implemented
to interact with any security provider the system designer
chooses.
The Security Service signs roles using a Private Key, to
which other Security Services have the corresponding Public
Key. This provides a mechanism by which platforms can trust
that the Roles assigned to the user were assigned by a trusted
source.
Role Based Access Control is included in this release through
the use of Service Permissions. This allows the creator
of a Component or the System Administrator to limit access
to each method within the interface for that component to
a particular Role or set of Roles. This limitation is provided
simply by generating a "secure"
RMIGSS connector, and a set of Policy files for the
component.
Audit of connector security may be performed by viewing
log files of applications providing services via secure
connector; see the explorer tutorial for information on
viewing log files remotely. The "security" and
"connector" log levels must be turned on; see
the troubleshooting
tutorial page for info on configuring log levels.
Feature History
- 1.1
- Updated Openwings Login Window to mitigate hidden
window problems
- o Added "Audit" logging level for logging
of information such as Login attempts
- 1.0
- Security Service Reference Implementation
- Openwings Core configured with "Secure"
connectors
- Role based access via ServicePermissions
- Install security
- 0.9.2
Known Issues
- Username, Password and Role information is stored on
the local platform rather than in a centralized repository.
This means that in order for Roles to be trusted across
platforms the signing entity stored in the KeyStore must
be the same across platforms. (See Setting
up Users/Roles)
- Login Window will sometimes pop up behind existing
windows, creating the illusion that Openwings is frozen.
Check to see if there is a login prompt displayed behind
other windows if Openwings seems to block for a long time
at startup. This has been addressed as much as possible
in Openwings 1.1, however due cross-platform limitations
of Java, the problem may still occur. In Windows, when
a login popup dialog appears behind other windows, the
taskbar icon for the login popup dialog will blink.
- The "Secure" RMI Connector has not been optimized
for performance, so it will be slower in some instances
than a normal connector.
- The JAAS NTLoginModule (supplied as part of Java), does
not work correctly on Windows NT 4.0 or Windows XP.
Future Releases
- Integration with Context Services
- Establishing Trust Relationships between platforms
- Secure Connector Enhancements: encryption, securing
out of band data
- Non-repudiation
- Auditor component
