Authorization Token Layer Acquisition Service (ATLAS)

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.

Common Secure Interoperability (CSIv2)

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 assumptions:

• Secure interoperability is predicated on the use of a common transport-layer security mechanism, such as that provided by SSL/TLS.

• 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 (SEC)

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 different needs. 

The security functionality defined by this specification comprises:

• 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 clearance).

• 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 objects. 

• 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 systems.

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  (RAD)

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 CORBA Security 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 little expertise).

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 Key infrastructures).

• 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.