Security In COBRA

Outline
n n n n n n

Overview Key Features Security model Replaceable security service Role of security interceptors How secure invocation is done

Overview
n n

Security is provided as a kind of CORBA services (not part of the core ORB) The CORBA security service provides a security architecture. Two levels of security defined: n level 1:
n n

Applications are unaware of the security mechanism. Users may be authenticated. applications can make use of objects to define their own security policies.

level 2:
n

Overview
Various consumers who dealing with security. n End users, n Application developers, n System administrators/security managers, and n Object system implementers.

Overview
CORBA Security as dealing with the following central elements:
n

Subject
A human user or system entity which, may attempt an action within a secure system.

Authentication
The act of establishing the identity of a subject. Once authenticated, the subject becomes a Principal.

Principal

An authenticated subject. Basically, this is any entity that directly or indirectly causes an invocation to be made against an object.

Overview
n

Credential

A container within a secure CORBA system for the security attributes associated with a principal.

Security Association

The result of establishment of trust between a specific client and server, possibly enduring several invocations.

Overview
n

Principals
n

Human users or system entities registered in and authentic to the system Each principal in a CORBA environment with Security Service is associated with credentials, Credentials contain security attributes of an object, Credentials are used for access controls, authentication, etc. An object may have several credentials, representing privileges in different domains

Credentials
n n n

Key (visible) Features

n

Authentication
n

Authorization
n

Is principal (user or object) who they claim to be? Does a principal has the right to perform an operation? Who is the source user (human) for an action? Ensure messages not corrupted and (optionally) not intercepted Irrefutable evidence that an action has been performed How do we define the policy?

Auditing
n

Communication
n

Non-repudiation
n

Administration
n

The security model:

User
Message protection, access control device, etc.

Client
requests

Server
ORB

Security Implementation enforcing security policy

Message protection, access control device, etc.

All object invocations are mediated by the security implementation No specific security policy defined in the model, so that a wide variety of different policies can be defined according to different needs

Replaceable sucurity services:

Replaceable security services are assumed to be implemented in combination with two different interceptores, Access control interceptor :
n n

Request-level interceptor. Checks the access rights associated with an invocation. Message-level interceptor. Implementing the message protection.

Secure invocation interceptor :

n n

Role of the security interceptors:

How secure invocation take place :

Steps to secure invocation : n The client interceptor send message to the object server with necessary informations. n Server creates a security context for subsequent invocations. n The response returned to the client includes additional informations.
n

n n

Security association done. From here security invocation can take place.

Vault object is called.

Thank you