The Challenges of CORBA Security

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

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

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

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

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

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

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

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

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

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

11. 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 • Identity • Privilege Principal Credential

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

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

14. 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)

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

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

17. 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 ?