This page is a resource for information regarding OMG Security
Specifications, providing descriptions and links to
security-related specifications. Two specifications, ATLAS and RAD,
provide security functionality at the API level and are catalogued on this
page. Two other specifications, CSIv2 and CORBA Security Service, provide
security enhancements to the CORBA infrastructure and are catalogued
elsewhere (but described here). Those catalog entries may be found within
the CORBA/IIOP and CORBAservices catalogs, respectively.
This page also provides links to supporting
information such as presentations.
The OMG Security Specifications available are:
Authorization Token Layer Acquisition
Describes the service needed to acquire
authorization tokens to access a target system using the CSIv2 protocol.
This design defines a single interface with which a client acquires an
authorization token. This token may be pushed, using the CSIv2 protocol in
order to gain access to a CORBA invocation on the target. This
specification solves the problem of acquiring the privileges needed for a
client to acquire a set of privileges the target will understand.
||Authorization Token Layer Acquisition Service (ATLAS)
||authorization, availability, confidentiality,
privacy, protocol, security, token
|Latest / past specifications:
Past versions: n/a
|Related OMG Specifications:
CSIv2, Naming Service,
|Related Industry Standards:
||ISO 10646, RFC 2044
Common Secure Interoperability, version 2
The Common Secure Interoperability Specification, Version
2 (CSIv2) defines the Security Attribute Service that enables
interoperable authentication, delegation, and privileges.
The SAS protocol is designed to exchange its protocol
elements in the service context of GIOP request and reply messages that
are communicated over a connection-based transport. The protocol is
intended to be used in environments where transport layer security, such
as that available via SSL/TLS or SECIOP, is used to provide message
protection (that is, integrity and or confidentiality) and
server-to-client authentication. The protocol provides client
authentication, delegation, and privilege functionality that may be
applied to overcome corresponding deficiencies in an underlying transport.
The SAS protocol facilitates interoperability by serving as the
higher-level protocol under which secure transports may be unified.
The SAS protocol was designed under the following
Secure interoperability is predicated on the use of a
common transport-layer security mechanism, such as that provided by
The transport layer provides message protection as
necessary to protect GIOP input and output request arguments.
The transport layer provides target-to-client
authentication as necessary to identify the target for the purpose of
ensuring that the target is the intended target.
Transport-layer security can ensure that the client
does not have to issue a preliminary request to establish a
confidential association with the intended target.
To support clients that cannot authenticate using
transport-layer security mechanisms, the SAS protocol shall provide
for client authentication above the transport layer.
To support the formation of security contexts using
GIOP service context, the SAS protocol shall require at most one
message in each direction to establish a security context.
The protocol shall support security contexts that
exist only for the duration of a single request/reply pair.
The protocol shall support security contexts that can
be reused for multiple request/reply pairs.
Targets cannot rely on clients to manage the lifecycle
of reusable security contexts accepted by the target.
Clients that reuse security contexts shall be capable
of processing replies that indicate that the context has been
discarded by the target.
CORBA Security Service
The assets of an enterprise need to be protected against
perceived threats. The amount of protection the enterprise is prepared to
pay for depends on the value of the assets, and the threats that need to
be countered. The security policy needed to protect against these threats
may also depend on the environment and how vulnerable the assets are in
this environment. This CORBA Security Service provides a security
architecture that can support a variety of security policies to meet
The security functionality defined by this specification
Identification and authentication of principals (human
users and objects that need to operate under their own rights) to
verify they are who they claim to be.
Authorization and infrastructure based access control
- deciding whether a principal can access an object domain, individual
object, or operation on an object, normally using the identity and/or
privilege attributes of the principal (such as role, groups, security
Security auditing to make users accountable for their
security related actions. It is normally the human user who should be
accountable. Auditing mechanisms should be able to identify the user
correctly, even after a chain of calls through many objects.
Security of communication between objects, which is
often over insecure lower layer communications. This requires trust to
be established between the client and target, which may require
authentication of clients to targets and authentication of targets to
clients. If also requires integrity protection and (optionally)
confidentiality protection of messages in transit between
Non-repudiation provided irrefutable evidence of
actions such as proof of origin of data to the recipient, or proof of
receipt of data to the sender to protect against subsequent attempts
to falsely deny the receiving or sending of the data.
The CORBA security model is security technology neutral.
For example, interfaces specified for security of client-target object
invocations hide the security mechanisms used from both the application
objects and ORB (except for some security administrative functions). It is
possible to implement CORBA security on a wide variety of existing
systems, reusing the security mechanisms and protocols native to those
The CORBA Security Service can control access to an application
object without it being aware of security, so it can be ported to
environments that enforce different security policies and use different
security mechanisms. However, if an object requires application level
security, the security attributes must be delegated and made available to
the application for access control.
This specification defines the core security facilities and
interfaces required to ensure a reasonable level of security of a CORBA-compliant
system as a whole.
Public Key Interface (PKI)
A Public Key Infrastructure (PKI) is a collection of
components or entities for the issuance, management, and revocation of
digital certificates. Public key technology, although not new, does have
promise as a basis for a flexible method of providing security in an
online and distributed environment. For public key technology to reach
this potential it must be possible to bind an identity to that of a
public/private key pair (digital certificates) and then subsequently
manage these using a PKI. This specification provides interfaces and
operations in CORBA IDL to support the functionality of a PKI. It
describes a generic interface that allows standards to be implemented
behind these interfaces and operations. The specification also takes into
consideration the possibility of specific CORBA extensions being designed
at a later date that utilize specific technology within the CORBA
framework. The interfaces provided in this specification describe a
standard method of interacting with PKI entities in a CORBA environment.
Resource Access Decision Facility
The lack of a framework to support fine-grain access
controls required by "application-level" security is a well
known problem in distributed computing. Privacy legislation in healthcare,
telecommunications, and financial domains demand more sophisticated access
control policies than what can be provided by infrastructure security
(such as CORBA and J2EE security). Infrastructure security services may
provide access control based on objects, object domains, and individual
operations on objects, however the information regarding the resources of
an application (features and/or data) requested by a user is often carried
in the parameters of operations and only understood as a secured resource
by business application itself. Infrastructure security services cannot
protect these application resources. The practical effect of not being
able to use an infrastructure security service (such as
Service) to express or realize application specific policies is that each
business application must contain its own implementation of an access
control facility (often coded as part of the business logic). This poses
severe problems for enterprises that need to define access policies that
are consistent across applications. Today, these policies are often coded
as part of the application that makes it impossible to administer and
maintain auditable access policies. It also places a burden on the ISV who
is now forced to develop and maintain configurable security access policy
engines for business applications (an area where they typically have
The OMG Resource Access Decision Facility (RAD) addresses
these problems. It provides a uniform way for application systems to
enforce resource-oriented access control policies. By standardizing this
service, we enable the enterprise to define and administer an Enterprise
Security Policy for use by all their software components - and allow these
components "plug-in" to the enterprise security.
The RAD service provides:
The ability to use credentials supplied by diverse
security mechanisms (including CORBA security, Public and/or Private
The ability to have Resource Access Decision (RAD)
facility delivered as a product by vendors who specialize in security
solutions. That is, the Authorization (access decision) service is
conceptually external to the application.
The ability to replace and/or augment the default
Policy Engines delivered by a RAD by vendors and/or end-users.
A very simple interface that product vendors use to
request access control decisions.
The ability for secured resources to be grouped for
the purpose of defining access control rules.
The ability to support consultation of multiple access
control policy and to control how multiple access control policy
decisions governing access to the same resource are reconciled.