Security and Interoperability Services

Security
Security is the process that aims at securing systems rather than the idealized state of absolute security itself. Security is often a nebulous thing. In large-scale projects involving enterprise middleware like EJB however the risks of a badly or altogether unprotected infrastructure can be enormous. Being secure means that no harmful events can happen to us and our assests (data,processes,infrastructure,whatever).

Violations
The events that we would like to avoid are often called as security breaches or violations.

Eg: An intruder reading files that we would prefer to remain confidential.

Vulnerabilities
A security violation is possible if there are no safeguards that protect against them, in other words no file system protection. Violations are possible if the system has weaknesses that allow users to circumvent security. Eg: A user can obtain another users privileges and thus access them. The above deficiencies are called as vulnerabilities, which can be exploited by those who find them.

Risk
The list of potential vulnerabilities is openended and increases with every piece of hardware or software that is added to a system, complete protection is not a realistic goal. As there is no perfect security anyway, it has become common practice to try to reduce the overall risks to an acceptable level.

Contd..
To reduce risks we need to perform a risk assessment before we can decide how much and what needs to be done. In simplest definition risk is a product of two factors: probability of the occurrence of violation and the estimated damage caused by this event.

Contd..
The probability of occurrence is a function of our systems vulnerabilities and the attackers resources. The potential damage is a function of the value of our assests. Eg: If we have a complex system with weak protections and a resourceful enemy, then the probability of a successful attack is high.

Understanding EJB Security

The are two security measures that clients must pass when we add security to an EJB system: authentication and authorization. Authentication must be performed before any EJB method is called. Authorization on the other hand occurs at the beginning of each EJB method call.

Authorization in EJB
After the client has been authenticated, it must pass an authentication test to call methods on our beans. The EJB container enforces authorization by defining security policies for our beans.

Contd..
There are two ways to perform authorization with EJB: With programmatic authorization, we can hard-code security checks into our bean code. Our business logic is interlaced with security checks. With declarative authorization, the container performs all authorization checks for us.

Contd..
We declare how we would like authorization to be achieved through the deployment descriptor, and the container generates all necessary security checks. We are effectively delegating the authorization to the EJB container.

Security Roles
A security role is a collection of client identities. For a client to be authorized to perform an operation its security identity must be in correct security role for that operation. The EJB deployer is responsible for associating the identities with the correct security roles after we write our beans.

Contd..
Specifying security roles in EJB is application server-specific but should not affect the portability of our code.

Security Role Employees Managers Administrators

Valid Identifier EmployeeA, EmployeeB ManagerA AdminA

Programmatic Authorization
To perform programmatic authorization three steps has to be followed: Step1: Write the programmatic security logic. Step2: Declare the abstract security roles our bean uses. Step3: Map abstract roles to actual roles.

Declarative Authorization
The primary difference between the two models is that with declarative authorization, we declare our beans authorization requirements in our deployment descriptor. The container enforces these requirements at runtime. To perform declarative authorization we have to follow two steps.

Contd..
Step1: Declare Method Permissions. Step2: Declare security roles.

Secure Interoperability
Secure interoperability means that EJB containers from different vendors cooperate in protecting EJB invocations that originate in one vendors product and target EJBs in another. The most important functionality that EJB containers must agree on here is the authentication of principals on one end of the invocation and the propagation of the principal information to the other.

Contd..
Any security information that needs to be exchanged must be standardized. Otherwise one vendor product would not be able to understand the information sent by its colleague on the other end of the wire. The general protocol that EJB specification requires for interoperability is RMI-IIOP.

Contd..
For additional security-related interoperability the EJB specification leverages two more protocols that were originally designed for CORBA. IIOP/SSL : for authentication, integrity and confidentiality. CSIv2 (Common Secure Interoperability Version 2): for additional authentication capabilities and principal propagation.

IIOP/SSL
SSL/TLS takes care of all the details of setting up secure transports between endpoints. The deployers has to just provide the proper credentials that SSL/TLS can use during its initial handshake. Internally the hosting EJB containers CORBA Object Request Broker(ORB) is equipped to insert SSL-level transport information into EJBObject references.

Contd..
For IIOP/SSL these references take the format of CORBA Interoperable Object References(IORs), and SSL/TLS-related information is stored in the IOR as tagged components. The receiving containers ORB recognizes the IOP and its tagged components and hence knows how to let the SSL/TLS layer open transport connections.

Disadvantage
SSL/TLS is not suitable for all security problems. It does offers interoperable, standardized means for mutual authentication between communicating peers, but it requires public key certificates in X.509 format to do this. Moreover, SSL/TLS is heavyweight in the sense that the initial handshake required to set up a secure transport adds a significant overhead.

CSIv2
CSIv2 was specified for CORBA by the Object Management Group (OMG) in 1999 as a successor to earlier secure interoperability protocols. CSIv2 was designed to be used together with transport-level SSL security and to complement it. The Security Attribute Service(SAS) protocol in CSIv2 defines additional client authentication functionality that is independent of SSL/TLS and can be used with kerberos or UseId/password schemes.

 Target authentication is not supported in SAS protocol so if mutual authentication is required, the SAS protocol must be combined with the transport-level target authentication offered by SSL/TLS. The CSIv2 protocol also supports identity assertions as a means of principal propagation.

Contd..
An identity assertion is sent by the calling client to tell the receiver that it should not consider the client identity for making authorization decisions, but the asserted identity instead. An asserted identity is much like a run-as statement or a set-uid bit in the UNIX file system.

Contd..
With identity assertions a single method call may have three different identities associated with it. The transport-level identity as established by SSL. An additional client identity established through SAS client authentication The asserted identity.

Contd..

Security attribute layer

Identity Assertion

Client authentication layer

Client Authentication Client Authentication Message Protection Target Authentication

Transport layer (SSL/TLS)

Thank you