Securing the Middleware Platform - Using SSL and/or CORBAsec L2?
Petra Hoepner
GMD FOKUS, Competence Center PLATIN, Kaiserin-Augusta-Allee 31, 10589 Berlin,
Germany
email: hoepner@fokus.gmd.de

Introduction: The PLATIN middleware platform (MWP) forms a processing
environment for an open service market supporting distributed applications that
can be managed, launched, and executed. This environment envisaged by TINA
(telecommunications information networking architecture) comprises heterogeneous
and interconnected DPE (distributed processing environment) nodes that fulfil
mainly two purposes: they hide technical and organizational heterogeneity, and
they present a target system that can help to ease the tasks for application
designers. The MWP is featuring access management including access, subscription
and profile management; service management including accounting management and
service customization; and communication management including streams and group
communication support. The implemented DPE of the MWP provides CORBA
transparencies such as access transparency (masking heterogeneity of the
underlying system) and location transparency (masking the location of components
of a distributed application). CORBAservices such as the Lifecycle Service,
Naming Service, Event Service are used across heterogeneous MWP-DPE nodes such
as C++:Orbix, VisiBroker, Cool;  ST:DST; Java:VisiBroker, OrbixWeb. 
The integration of a Security Service is required. This led to the following
questions: use SSL or integrate a Level 2 CORBAsec product? Constraints for a
security service are: user access to services can be done by 'normal' web
browsers or dedicated JAVA programs communicating via HTTP or IIOP; user
authentication and coarse grained authorization is provided by a subscription
component (single sign-on), a user profile is communicated between access and
service session; usage and service session may be based on a different
infrastructure, i.e. different products.
An evaluation of the different DOCsec possibilities is shortly presented below.

SSL
Positive: CORBAsec interoperability conformant; general acceptance, widely used
in Internet environment; certificate based authentication supported; multi-party
security (client and server certificates); secure channel provided, i.e.
communication security (integrity and confidentiality); available in CORBA and
Internet environment; interworking of products seems possible
Negative: two party (client-server) connection, not 'end-to-end'; no
authorization, no delegation of attributes; no auditing (product-specific
logging possible); product specific export restrictions on key size; no API
(product specific access to functionality)

CORBAsec Level 2 (Products)
Positive: security targets (authentication, authorization, auditing, secure
communication) partly or completely fulfilled by products; IDL interfaces;
standardized architecture;
Negative: products are dedicated to specific ORBs; product-specific mechanisms
for authentication, authorization, auditing (if supported at all); integration
of legacy security components (authentication, authorization, logging systems)
not possible; mechanism replacement not possible (e.g. via GSS-API);
interworking of products not possible and/or not tested

Questions to DOCsec  product vendors
- Support of portable interceptors? Generic DOCsec products (for different ORBs
intended?)
- Security components for flexible needs (e.g. integration of legacy security
systems)?
- Replaceable security building blocks (e.g. DCE based to SESAME based)?
- SSL-based extended security services in future (e.g. authorization and
delegation support)?
- Firewall issues:  integration of existing non-CORBA firewalls, provision of
CORBA-firewalls?
- PKI integration as in Public Key Infrastructure RFP specified - intended?
- Key issue - interworking: how approached now and in the future?
- ...