- Email: [email protected]
Security in CORBA distributed object systems
Information Security Technical Report, Vol. 1, No. 2 (1996) 56-63
Security in CORBA Distributed Object Systems Belinda Fairthorne, ZCL Ltd This article takes a more technical look at distributed systems using object orientation and describes the initiatives of OMG - the Object Management Group.
Introduction Object-oriented technology is becoming increasing popular for building applications and systems including large, distributed ones. However, users have recognised the need for such distributed systems to be secure and vendors are responding to these needs. This article looks at the CORBA Security standard recently adopted by the Object Management Group (OMG) and how it provides the required security with sufficient flexibility to meet the security needs of different enterprises. Belinda Fairthorne is an ICL Security Architect who has worked for a number of years on security in distributed systems, for example, as part of the European SESAME project for security in open systems. She was chair of the OMG Security working group specifying the requirement for OMG security and also chief editor of the CORBA Security specification produced in response to these.
Object Systems and why they are important People are familiar with objects in the real world - for example, people, banks, cars etc.. Objects in an IT system can reflect this real world view. An object is a component which contains data and provides operations for others to
56
manipulate that data. Other components see only the interface the object offers, they do not see the internal structure of the data or know which other objects may need to be invoked to complete the operation. Advantages of object systems include: Easier business modelling and design as the information system objects reflect the real world ones more naturally so are easier to understand. Easier re-use of components when building new applications. Because interfaces to objects are well-defined, it is easier to see if an existing object meets the needs of the new application. Easy creation of specialised versions of objects (e.g. a Rolls Royce as a specialisation of a car) using object inheritance to create the new car, then specialising it to add its new attributes. As data is ‘encapsulated within objects, a change in one object will normally not affect other objects. Applications become more modular, and have better flexibility to grow. Existing components can be fitted into an object system by creating a software layer around it to provide an object interface to it. The above characteristics lead to better flexibility to change, reduced time to market, better programmer productivity and make it easier to create complex distributed applications.
0167-4048/96/$15.00
0 1996, Elsevier Science Ltd
Security in Corba Distributed Object Systems
The Object Management Group (OMG) and The CORBA Security Standard OMG is a consortium which was formed in 1989 to create a component-based software market place by hastening the introduction of standardised object software. It has grown from 8 companies to over 600 members and is now the largest such consortium. Part of ‘OMG’s charter is to establish object management specifications to provide a common framework for application development. The Common Object Request Broker Architecture (CORBA) Security specification was adopted as an OMG standard earlier this year. A Common Secure Interoperability specification has now been produced to add standard security mechanisms for secure This was voted for interoperability. unanimously at a recent OMG meeting, and is now going through a formal vote. Both specifications were produced by a group of vendors - the main ones being ICL, IBM, Digital, Bull, HP, Siemens, Sun and Tandem supported by NSA and others.
Requirements for CORBA Security Today’s businesses are increasingly dependent on Information Technology to handle their critical information and processes. Each year, security breaches cost billions of pounds, and the security threats are increasing. The move to more distributed systems, such as distributed object systems, increases the vulnerability. There are more places to attack - more nodes and more networks between them. Also, management is often devolved, with different security policies used in different places so it may be difficult to set up and manage the total distributed system securely. The CORBA Security standard must provide security for object systems which are often
Information Security Technical Report, Vol. 1, No. 2
distributed, are increasingly large heterogeneous ones and are continually evolving. It needs to satisfy the different security needs of a range of commercial and also government organizations. Organizations may need assurance of how effective the security is; some may even require formal evaluation of this. Particular requirements identified are: Usability: particularly for application developers and administrators. Most developers should not need to know about or understand security or they may become the weak link in the chain. ScuZubility:so the system can support many users and objects. For example, it should not be necessary to specify controls for each user and object individually, Flexibility: so different organizations can use the security policies and mechanisms which best suit their needs. Consistency: it should be possible to have a consistent security policy across the nodes of a distributed, heterogeneous object system. This should also fit with the security used outside the object system. Deployable internationally: it should allow conformance with different national and international regulations on the use and export of cryptography. Performance: should not be unduly impacted by the addition of security.
The CORBA Security specifications The CORBA Security standard includes a model for use of security in CORBA systems as well as the facilities and interfaces for applications, administrators and ORB/security implementors to use. The Common Security Interoperability
57
Security in Corba Distributed
Object Systems
part defines the common security mechanisms to use for secure interoperability and describes the effect of those mechanisms on the CORBA Security facilities. Chosen mechanisms are ones which are also available outside OMG systems.
mediated by an Object Request Broker (ORB). The ORB locates that object and passes the client’s request to it. When the target object has performed the operation, it returns a reply to the client via the ORB.
CORBA Security defines security in distributed object systems as encompassing: ??
??
??
Corzfi&ntiulity: information is disclosed only to authorised users. Integrity: information is modified only by authorised users in authorised ways. It is only transferred between intended users in intended ways. Accountability: users are accountable their security related actions.
for
As in other systems, security is enforced using: Authentication: to prove that the user (or system entity) is who he claims to be.
In a secure CORBA object system, the same client calls the same target object. Security services are automatically invoked by the ORB at both the client and the target without the application being aware that its requests and replies are being secured. However, applications which want to enforce their own security controls can call on the security services directly themselves.
Access controls: to control what the user can access in the system. Secure communications: to protect information in transit between components. Security auditing: to record and analyse what the user does in the system. Non-repudiation: to provide evidence of actions.
irrefutable
Security administration: to manage security information including security policies. The CORBA Security Model and Facilities CORBA Security is now part of the OMG Object Management Architecture. In this, a client requests a target object to perform an operation
58
It is important that object implementations do not need to be changed to fit into and be protected by, a secure object system. A distributed application may be made up of many small objects and it is unusual for all the application developers to be sufficiently security knowledgeable to make the right calls on the security facilities. Also, if security is part of the ORB, it is easier for administrators to manage it
Information Security Technical Report, Vol. 1, No. 2
Security in Corba Distributed Object Systems
(for example, by mutual authentication) and the principal’s attributes are passed to the target for use in access controls and auditing there. Security associations generally last for multiple requests.
and it is much more difficult to bypass the security controls - the ORB and supporting software can form a Trusted Computing Base. There is also less code responsible for enforcing security which should ease evaluation of secure object systems. ??
Security in a secure distributed CORBA system starts with a user (or other principal) authenticating to the system, for example, by logging on. (This may be done outside the object system.) As the result of this authentication, Credentials are created which contain the security attributes of the user. These include, for example, the identity and other privileges the user has such as roles, groups and security clearance. Unauthenticated users may also have credentials, but limited attributes which only allow access to objects which are publicly available. When an object is invoked by an ORB, the credentials are used to identify who was responsible for this invocation.
\Ob,ect
Request BT
During object invocation, security may be enforced at the client or at the target side, or both. This includes some or all of the following: ??
??
Access contds: These check if this client (on behalf of this principal) is allowed to perform this operation on this object. Permission to perform this operation may also depend on context, such as the time the call was made. Setting up ‘security associations’: The client and target establish if they trust each other
Information Security Technical Report, Vol. 1, No. 2
??
Message protection: The individual requests and replies sent between client and target can be protected for integrity and optionally confidentiality. Auditing: provides a record relevant events when needed.
of security
Managing security in a secure CORBA system The CORBA Security specification defines how to manage security policies. These policies are mainly concerned with the security during object invocation and specify the access controls, type of auditing and message protection etc., which is to be enforced automatically. It is also possible to define application level security policies, and manage them in a similar way to the invocation policies if the application enforces security using the same sort of policy objects as the ORB uses. Management of users and their security information (e.g. their authentication information and permitted privileges) is not included in the CORBA Security specification. This is to allow, for example, Single Sign-on to both object and other systems with the user information managed by the existing security services. It also allows flexibility in the choice of authentication and security mechanisms used. For example, if public key technology is used for distribution of cryptographic keys, management of users could imply management of their public key certificates; if secret key technology were used, secret keys will need to be managed at a security server.
59
Security in Corba Distributed Object Systems
Security Policies and Domains A security policy domain is the set of objects to which a security policy applies. All objects belong to security policy domains. There is a domain manager for each security policy domain which is used when finding and managing the policies associated with the domain.
and with objects for the bank accounts at that branch. The bank branch is a security policy domain. The type of employee is identified by a ‘role’ privilege in his credentials. This will be set as the result of authentication and privilege acquisition. Credentials for Bob
OhJecls
enclosing
Name Bob
There can be several security policies associated with each domain- policies to enforce different types of control (e.g. access or audit) are implemented in separate policy objects, as are client-side and target-side policies. An object is governed by the policies of its enclosing domains, so enterprise wide policies may be specified for an enterprise domain, where more local controls may apply to a smaller domain of objects within this. The ORB calls on policy objects to enforce policies during object invocation. The policy objects also support policy administration, for example, changing which requests are to be audited. Policy objects can be replaced if a different type of policy is wanted, for example, a label based access policy instead of an Access Control List (ACL) based one. Domain Access Policy A standard access policy is specified - the Domain Access Policy. This enforces the access policy using an Access Control List. For example, consider a bank branch with two types of employees (bank managers and bank clerks)
60
Role
etc
Bank Manager
The access policy specifies the effective rights that someone with the specified privileges (in this case role) has in that domain. In this example, bank managers have get and set rights where bank clerks only have get rights. Access Policy for Domain
The system also knows what rights are required for operations on each type of object. In the example, the get right is required for operations such as see-credit-status on a bank account, but the set right is needed to use the debit-account operation. So bank clerks can see, but not update accounts. Required Rights for Bank Accounts Right
get set
operations read_account_value see_credit_status creditgccount debit-account
Information Security Technical Report, Vol. 1, No. 2
Security in Corba Distributed Object Systems
This split of information is for ease of administration. If a new bank clerk joins the bank, his role needs to be specified, but he will be able to access accounts without the access policy for the domain or the required rights for bank accounts being updated. Policies may be changed to allow users with a particular role to have different rights without the user information being changed. The required rights for all bank accounts can be defined once however many accounts are added or deleted. Other Security Policies The audit policy specifies under what circumstances object invocations will be audited. It specifies which types of event to audit (e.g. the object invocation itself or just the access control check), for which objects and whether to record only failed events or ones at specified times etc. In an object system, there is rarely just a single client and target object. A call on an object often results in a chain of calls on other objects. Each of the intermediate objects acts as a target object when called by the previous one in the chain, and then as a client calling another target object.
provided automatically during object invocation without applications being aware of it. However, some applications want to enforce some security themselves. An application may want to control who can access its own functions and data, in a way which the automatic policy used on object invocation cannot do. For example, controls may need to depend on the value of data within the object. Similarly, applications may audit their own functions. Applications can also influence the transparently enforced security during object invocation, for example, ask for a particular message to be confidentiality protected. However, they cannot override the mandatory policies. Authentication of users (and other principals) can be done by applications using facilities within the object system. However, few applications should need this, as user authentication is generally done by special logon software.
Non-repudiation An application can also use non-repudiation
In this case, a delegation policy specifies which principal’s attributes to pass from an intermediate object to the target. The intermediate may pass its own, delegate the ones it received, or pass both.
functions to provide irrefutable proof of actions. For example, it may want to generate evidence of ‘proof of creation’ of a message. It may then send the message with the evidence to some one else (possibly via several intermediates). The final target verifies the evidence (to make sure it comes from the right person etc.,) before acting on it.
Security facilities for applications The security
facilities
described
so far are
Information Security Technical Report, Vol. 1, No. 2
61
Security in Corba Distributed Object Systems
The evidence normally includes information to prove the integrity of the data, the date/time, who guaranteed it and the type of action. The credentials of the initiator are used when generating evidence which will generally include digital signatures (though CORBA does not mandate what security technology is used). The application is responsible for sending the evidence to the target, or storing it (for use in settling future disputes). The way this is done is up to the application and will vary for different types of application. The target may send back evidence to prove receipt of the message (not shown in the diagram above). Interoperability Secure interoperability builds on the CORBA 2 interoperability standard. The interoperable object reference (IOR) defines what security the target requires (e.g. how it wants messages to be protected) and what it supports (including security mechanisms). Security tokens are added to the protocol to establish the security association and to protect messages.
authentication and protect messages. CORBA Security can be implemented using different security mechanisms and cryptographic algorithms. The choice of mechanism depends on the facilities wanted (e.g. whether privileges such as roles are needed for access control), what mechanism is used outside the object system, national government regulations on the use and export of cryptography etc.. The following security mechanisms are specified for use with the CORBA interoperability standard (IIOP) as part of the secure interoperability standard. All can be used in heterogeneous systems and will be available in CORBA Security implementations. Kerberos: This passes the initiator’s identity only (not other privileges) for access control and audit and supports delegation with no controls. It uses secret key technology. SESAME: This can pass a range of privileges as well as an identity for access control, and has delegation controls. It has secret and public key technology options and replaceable algorithms. SPKM: This passes the initiator’s identity only and does not support delegation. It uses public key technology.
The type of security tokens for interoperability (e.g. establish context, message in context) are standard for all security mechanisms but the details are mechanism specific.
Conformant secure interoperable ORBS will support Kerberos and optionally SESAME and SPKM. Of these three, only SESAME supports the full CORBA security facilities for example, access controls using roles and other privileges, as well as identities. Both SPKM and SESAME include public key technology and both use X.509 V3 certificates and associated certificate management. This technology will also be used to provide digital signatures for non-repudiation.
Security associations generally distribution of keys to support
There is also a DCE CIOP protocol and DCE security can be used with this. DCE security can
62
rely on (mutual)
Information Security Technical Report, Vol. 1, No. 2
Security in Corba Distributed Object Systems
pass a range of privilege attributes and supports controlled delegation. It uses secret key technology.
Conformance to the CORBA Security Specification Not all conformant ORBS need support all facilities defined in the CORBA Security specification. It is mandatory to provide a specified security facilities during object invocation and to allow applications to provide their own access controls using the l&incipal’s identity and privileges. Level 2 conformance includes a wider range of facilities for applications and also includes the specified policy administration. Further options specify non-repudiation, conformance to implementation interfaces (to allow replaceable security services ) and interoperability options.
Summary In summary, CORBA Security requirements are general distributed security ones, though the complexity of the larger object systems with many objects requires CORBA Security to be leading edge. CORBA Security allows object systems to provide security suitable for both commercial and government users as it has a good range of facilities and a choice of policies. It provides security for security unaware applications, so these do not need to be re-written to fit into a secure environment so easing the transition to secure object systems. CORBA Security does not mandate particular security mechanisms so it is possible to fit with existing suitable mechanisms already in use. However, the Common Security Interoperability standard is specifying standard mechanisms. A number of implementations of this standard are underway (including one by ICL in its DAIS product - URL: www.icl.com/dais).
Information Security Technical Report, Vol. 1, No. 2
63
Security in CORBA Distributed Object Systems Belinda Fairthorne, ZCL Ltd This article takes a more technical look at distributed systems using object orientation and describes the initiatives of OMG - the Object Management Group.
Introduction Object-oriented technology is becoming increasing popular for building applications and systems including large, distributed ones. However, users have recognised the need for such distributed systems to be secure and vendors are responding to these needs. This article looks at the CORBA Security standard recently adopted by the Object Management Group (OMG) and how it provides the required security with sufficient flexibility to meet the security needs of different enterprises. Belinda Fairthorne is an ICL Security Architect who has worked for a number of years on security in distributed systems, for example, as part of the European SESAME project for security in open systems. She was chair of the OMG Security working group specifying the requirement for OMG security and also chief editor of the CORBA Security specification produced in response to these.
Object Systems and why they are important People are familiar with objects in the real world - for example, people, banks, cars etc.. Objects in an IT system can reflect this real world view. An object is a component which contains data and provides operations for others to
56
manipulate that data. Other components see only the interface the object offers, they do not see the internal structure of the data or know which other objects may need to be invoked to complete the operation. Advantages of object systems include: Easier business modelling and design as the information system objects reflect the real world ones more naturally so are easier to understand. Easier re-use of components when building new applications. Because interfaces to objects are well-defined, it is easier to see if an existing object meets the needs of the new application. Easy creation of specialised versions of objects (e.g. a Rolls Royce as a specialisation of a car) using object inheritance to create the new car, then specialising it to add its new attributes. As data is ‘encapsulated within objects, a change in one object will normally not affect other objects. Applications become more modular, and have better flexibility to grow. Existing components can be fitted into an object system by creating a software layer around it to provide an object interface to it. The above characteristics lead to better flexibility to change, reduced time to market, better programmer productivity and make it easier to create complex distributed applications.
0167-4048/96/$15.00
0 1996, Elsevier Science Ltd
Security in Corba Distributed Object Systems
The Object Management Group (OMG) and The CORBA Security Standard OMG is a consortium which was formed in 1989 to create a component-based software market place by hastening the introduction of standardised object software. It has grown from 8 companies to over 600 members and is now the largest such consortium. Part of ‘OMG’s charter is to establish object management specifications to provide a common framework for application development. The Common Object Request Broker Architecture (CORBA) Security specification was adopted as an OMG standard earlier this year. A Common Secure Interoperability specification has now been produced to add standard security mechanisms for secure This was voted for interoperability. unanimously at a recent OMG meeting, and is now going through a formal vote. Both specifications were produced by a group of vendors - the main ones being ICL, IBM, Digital, Bull, HP, Siemens, Sun and Tandem supported by NSA and others.
Requirements for CORBA Security Today’s businesses are increasingly dependent on Information Technology to handle their critical information and processes. Each year, security breaches cost billions of pounds, and the security threats are increasing. The move to more distributed systems, such as distributed object systems, increases the vulnerability. There are more places to attack - more nodes and more networks between them. Also, management is often devolved, with different security policies used in different places so it may be difficult to set up and manage the total distributed system securely. The CORBA Security standard must provide security for object systems which are often
Information Security Technical Report, Vol. 1, No. 2
distributed, are increasingly large heterogeneous ones and are continually evolving. It needs to satisfy the different security needs of a range of commercial and also government organizations. Organizations may need assurance of how effective the security is; some may even require formal evaluation of this. Particular requirements identified are: Usability: particularly for application developers and administrators. Most developers should not need to know about or understand security or they may become the weak link in the chain. ScuZubility:so the system can support many users and objects. For example, it should not be necessary to specify controls for each user and object individually, Flexibility: so different organizations can use the security policies and mechanisms which best suit their needs. Consistency: it should be possible to have a consistent security policy across the nodes of a distributed, heterogeneous object system. This should also fit with the security used outside the object system. Deployable internationally: it should allow conformance with different national and international regulations on the use and export of cryptography. Performance: should not be unduly impacted by the addition of security.
The CORBA Security specifications The CORBA Security standard includes a model for use of security in CORBA systems as well as the facilities and interfaces for applications, administrators and ORB/security implementors to use. The Common Security Interoperability
57
Security in Corba Distributed
Object Systems
part defines the common security mechanisms to use for secure interoperability and describes the effect of those mechanisms on the CORBA Security facilities. Chosen mechanisms are ones which are also available outside OMG systems.
mediated by an Object Request Broker (ORB). The ORB locates that object and passes the client’s request to it. When the target object has performed the operation, it returns a reply to the client via the ORB.
CORBA Security defines security in distributed object systems as encompassing: ??
??
??
Corzfi&ntiulity: information is disclosed only to authorised users. Integrity: information is modified only by authorised users in authorised ways. It is only transferred between intended users in intended ways. Accountability: users are accountable their security related actions.
for
As in other systems, security is enforced using: Authentication: to prove that the user (or system entity) is who he claims to be.
In a secure CORBA object system, the same client calls the same target object. Security services are automatically invoked by the ORB at both the client and the target without the application being aware that its requests and replies are being secured. However, applications which want to enforce their own security controls can call on the security services directly themselves.
Access controls: to control what the user can access in the system. Secure communications: to protect information in transit between components. Security auditing: to record and analyse what the user does in the system. Non-repudiation: to provide evidence of actions.
irrefutable
Security administration: to manage security information including security policies. The CORBA Security Model and Facilities CORBA Security is now part of the OMG Object Management Architecture. In this, a client requests a target object to perform an operation
58
It is important that object implementations do not need to be changed to fit into and be protected by, a secure object system. A distributed application may be made up of many small objects and it is unusual for all the application developers to be sufficiently security knowledgeable to make the right calls on the security facilities. Also, if security is part of the ORB, it is easier for administrators to manage it
Information Security Technical Report, Vol. 1, No. 2
Security in Corba Distributed Object Systems
(for example, by mutual authentication) and the principal’s attributes are passed to the target for use in access controls and auditing there. Security associations generally last for multiple requests.
and it is much more difficult to bypass the security controls - the ORB and supporting software can form a Trusted Computing Base. There is also less code responsible for enforcing security which should ease evaluation of secure object systems. ??
Security in a secure distributed CORBA system starts with a user (or other principal) authenticating to the system, for example, by logging on. (This may be done outside the object system.) As the result of this authentication, Credentials are created which contain the security attributes of the user. These include, for example, the identity and other privileges the user has such as roles, groups and security clearance. Unauthenticated users may also have credentials, but limited attributes which only allow access to objects which are publicly available. When an object is invoked by an ORB, the credentials are used to identify who was responsible for this invocation.
\Ob,ect
Request BT
During object invocation, security may be enforced at the client or at the target side, or both. This includes some or all of the following: ??
??
Access contds: These check if this client (on behalf of this principal) is allowed to perform this operation on this object. Permission to perform this operation may also depend on context, such as the time the call was made. Setting up ‘security associations’: The client and target establish if they trust each other
Information Security Technical Report, Vol. 1, No. 2
??
Message protection: The individual requests and replies sent between client and target can be protected for integrity and optionally confidentiality. Auditing: provides a record relevant events when needed.
of security
Managing security in a secure CORBA system The CORBA Security specification defines how to manage security policies. These policies are mainly concerned with the security during object invocation and specify the access controls, type of auditing and message protection etc., which is to be enforced automatically. It is also possible to define application level security policies, and manage them in a similar way to the invocation policies if the application enforces security using the same sort of policy objects as the ORB uses. Management of users and their security information (e.g. their authentication information and permitted privileges) is not included in the CORBA Security specification. This is to allow, for example, Single Sign-on to both object and other systems with the user information managed by the existing security services. It also allows flexibility in the choice of authentication and security mechanisms used. For example, if public key technology is used for distribution of cryptographic keys, management of users could imply management of their public key certificates; if secret key technology were used, secret keys will need to be managed at a security server.
59
Security in Corba Distributed Object Systems
Security Policies and Domains A security policy domain is the set of objects to which a security policy applies. All objects belong to security policy domains. There is a domain manager for each security policy domain which is used when finding and managing the policies associated with the domain.
and with objects for the bank accounts at that branch. The bank branch is a security policy domain. The type of employee is identified by a ‘role’ privilege in his credentials. This will be set as the result of authentication and privilege acquisition. Credentials for Bob
OhJecls
enclosing
Name Bob
There can be several security policies associated with each domain- policies to enforce different types of control (e.g. access or audit) are implemented in separate policy objects, as are client-side and target-side policies. An object is governed by the policies of its enclosing domains, so enterprise wide policies may be specified for an enterprise domain, where more local controls may apply to a smaller domain of objects within this. The ORB calls on policy objects to enforce policies during object invocation. The policy objects also support policy administration, for example, changing which requests are to be audited. Policy objects can be replaced if a different type of policy is wanted, for example, a label based access policy instead of an Access Control List (ACL) based one. Domain Access Policy A standard access policy is specified - the Domain Access Policy. This enforces the access policy using an Access Control List. For example, consider a bank branch with two types of employees (bank managers and bank clerks)
60
Role
etc
Bank Manager
The access policy specifies the effective rights that someone with the specified privileges (in this case role) has in that domain. In this example, bank managers have get and set rights where bank clerks only have get rights. Access Policy for Domain
The system also knows what rights are required for operations on each type of object. In the example, the get right is required for operations such as see-credit-status on a bank account, but the set right is needed to use the debit-account operation. So bank clerks can see, but not update accounts. Required Rights for Bank Accounts Right
get set
operations read_account_value see_credit_status creditgccount debit-account
Information Security Technical Report, Vol. 1, No. 2
Security in Corba Distributed Object Systems
This split of information is for ease of administration. If a new bank clerk joins the bank, his role needs to be specified, but he will be able to access accounts without the access policy for the domain or the required rights for bank accounts being updated. Policies may be changed to allow users with a particular role to have different rights without the user information being changed. The required rights for all bank accounts can be defined once however many accounts are added or deleted. Other Security Policies The audit policy specifies under what circumstances object invocations will be audited. It specifies which types of event to audit (e.g. the object invocation itself or just the access control check), for which objects and whether to record only failed events or ones at specified times etc. In an object system, there is rarely just a single client and target object. A call on an object often results in a chain of calls on other objects. Each of the intermediate objects acts as a target object when called by the previous one in the chain, and then as a client calling another target object.
provided automatically during object invocation without applications being aware of it. However, some applications want to enforce some security themselves. An application may want to control who can access its own functions and data, in a way which the automatic policy used on object invocation cannot do. For example, controls may need to depend on the value of data within the object. Similarly, applications may audit their own functions. Applications can also influence the transparently enforced security during object invocation, for example, ask for a particular message to be confidentiality protected. However, they cannot override the mandatory policies. Authentication of users (and other principals) can be done by applications using facilities within the object system. However, few applications should need this, as user authentication is generally done by special logon software.
Non-repudiation An application can also use non-repudiation
In this case, a delegation policy specifies which principal’s attributes to pass from an intermediate object to the target. The intermediate may pass its own, delegate the ones it received, or pass both.
functions to provide irrefutable proof of actions. For example, it may want to generate evidence of ‘proof of creation’ of a message. It may then send the message with the evidence to some one else (possibly via several intermediates). The final target verifies the evidence (to make sure it comes from the right person etc.,) before acting on it.
Security facilities for applications The security
facilities
described
so far are
Information Security Technical Report, Vol. 1, No. 2
61
Security in Corba Distributed Object Systems
The evidence normally includes information to prove the integrity of the data, the date/time, who guaranteed it and the type of action. The credentials of the initiator are used when generating evidence which will generally include digital signatures (though CORBA does not mandate what security technology is used). The application is responsible for sending the evidence to the target, or storing it (for use in settling future disputes). The way this is done is up to the application and will vary for different types of application. The target may send back evidence to prove receipt of the message (not shown in the diagram above). Interoperability Secure interoperability builds on the CORBA 2 interoperability standard. The interoperable object reference (IOR) defines what security the target requires (e.g. how it wants messages to be protected) and what it supports (including security mechanisms). Security tokens are added to the protocol to establish the security association and to protect messages.
authentication and protect messages. CORBA Security can be implemented using different security mechanisms and cryptographic algorithms. The choice of mechanism depends on the facilities wanted (e.g. whether privileges such as roles are needed for access control), what mechanism is used outside the object system, national government regulations on the use and export of cryptography etc.. The following security mechanisms are specified for use with the CORBA interoperability standard (IIOP) as part of the secure interoperability standard. All can be used in heterogeneous systems and will be available in CORBA Security implementations. Kerberos: This passes the initiator’s identity only (not other privileges) for access control and audit and supports delegation with no controls. It uses secret key technology. SESAME: This can pass a range of privileges as well as an identity for access control, and has delegation controls. It has secret and public key technology options and replaceable algorithms. SPKM: This passes the initiator’s identity only and does not support delegation. It uses public key technology.
The type of security tokens for interoperability (e.g. establish context, message in context) are standard for all security mechanisms but the details are mechanism specific.
Conformant secure interoperable ORBS will support Kerberos and optionally SESAME and SPKM. Of these three, only SESAME supports the full CORBA security facilities for example, access controls using roles and other privileges, as well as identities. Both SPKM and SESAME include public key technology and both use X.509 V3 certificates and associated certificate management. This technology will also be used to provide digital signatures for non-repudiation.
Security associations generally distribution of keys to support
There is also a DCE CIOP protocol and DCE security can be used with this. DCE security can
62
rely on (mutual)
Information Security Technical Report, Vol. 1, No. 2
Security in Corba Distributed Object Systems
pass a range of privilege attributes and supports controlled delegation. It uses secret key technology.
Conformance to the CORBA Security Specification Not all conformant ORBS need support all facilities defined in the CORBA Security specification. It is mandatory to provide a specified security facilities during object invocation and to allow applications to provide their own access controls using the l&incipal’s identity and privileges. Level 2 conformance includes a wider range of facilities for applications and also includes the specified policy administration. Further options specify non-repudiation, conformance to implementation interfaces (to allow replaceable security services ) and interoperability options.
Summary In summary, CORBA Security requirements are general distributed security ones, though the complexity of the larger object systems with many objects requires CORBA Security to be leading edge. CORBA Security allows object systems to provide security suitable for both commercial and government users as it has a good range of facilities and a choice of policies. It provides security for security unaware applications, so these do not need to be re-written to fit into a secure environment so easing the transition to secure object systems. CORBA Security does not mandate particular security mechanisms so it is possible to fit with existing suitable mechanisms already in use. However, the Common Security Interoperability standard is specifying standard mechanisms. A number of implementations of this standard are underway (including one by ICL in its DAIS product - URL: www.icl.com/dais).
Information Security Technical Report, Vol. 1, No. 2
63