The Challenges of CORBA Security A Alireza U

The Challenges of CORBA Security A. Alireza, U. Lang, M. Padelis, R. Schreiner, M. Schumacher “It is important to understand that [CORBAsecurity] is only a (powerful) security toolbox and not the solution to all security problems. ” Presented by Roneel Naidu

Outline of Presentation • • • What is CORBA? CORBA Security Service Access Control Conclusion Questions

What is CORBA ? (1) • Traditional Client-Server Model Client • Server What happens when ? • • Many Clients and Servers over some network Implemented in different languages Running on different platforms, etc Want to do distributed computing!

What is CORBA ? (2) • Introduce a Middleman – Object Request Broker (ORB) • The ORB is like a software bus Client Server ORB • Note: Client/Server are just roles – can change

What is CORBA ? (3) • Interact with ORB through language and platform independent interfaces (IDL) Client Logical Server IDL ORB • Objects / Components deal with each other as if they are local.

What is CORBA ? (4) • Different ORB’s communicate with each other through a standard protocol (IIOP) Client Logical Server IDL IIOP ORB

What is CORBA ? (5) • CORBA – Common Object Request Broker Architecture – A specification that can be complied to by ORB manufacturer’s – Says what a CORBA compliant ORB should do, not how – Only defines core functionality

What is CORBA ? (6) • Object Services – Are outside the ORB Client Server – Examples: • Naming Service • Trading Service • Transaction Service ORB • Security Service (CORBAsec) Object Service

CORBA Security Service (1) • Like CORBA is just a specification that vendors can implement • Covers aspects of security and defines the implementation details for each aspect. • Does not specify security mechanisms to be used – Like a Framework ? – But type of security technology influences available features • Objects do not need to know about security – Security Service mediates calls as they are processed by the ORB

CORBA Security Service (2) • Principle – Entities that first cause some security relevant event – Human user or System entity that can authenticate itself • Usually by some ‘secret’ key. i. e. password Principal

CORBA Security Service (3) • Credential – All information that CORBAsec requires to decide what its principal is and isn't allowed to do – Contains two types of Attributes Principal • Identity • Privilege Credential

Access Control (1) • What methods (services) can some client invoke on some server ? • Two places that access control could be done Client Server – Component Level – ORB Level Request • CORBAsec does it at ORB level ORB

Access Control (2) • Access Decision Function – Simple yes/no Client Security Attributes Server Control Attributes ADF Decision

Access Control (3) • Many Users – Administrators can’t keep track of individual requirements – Groups – kept in Credentials • Many Servers – Administrators can’t keep track of individual requirements – Policies assignable to many servers • But need to group operations as well (Access Rights)

Access Control (4) • So we have predefined Access Rights that are known to both developers and administrators – Only a few currently – Do not fit all application scenarios – Thus (currently) better to implement access control at component level

Conclusion • Because CORBA Security has to be broad enough to be applicable in many different areas, but specific enough to be useful – It will not be able to fit into all security situations – But does allow for alternate means

Questions • Using predefined access rights, is there another (better) way ? – Managing many (1000’s) of clients and servers • What are the problems of doing access control at component level ?