security and interoperability services

8/2/2019 Security and Interoperability Services

1/28

Security and Interoperability

Services


2/28

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 badlyor altogether unprotected infrastructure can beenormous.

Being secure means that no harmful events canhappen to us and our assests(data,processes,infrastructure,whatever).


3/28

Violations

The events that we would like to avoid areoften called as security breaches or violations.

Eg: An intruder reading files that we would

prefer to remain confidential.


4/28

Vulnerabilities A security violation is possible if there are no

safeguards that protect against them, in otherwords no file system protection.

Violations are possible if the system hasweaknesses that allow users to circumventsecurity. Eg: A user can obtain another usersprivileges and thus access them.

The above deficiencies are called asvulnerabilities, which can be exploited by thosewho find them.


5/28

Risk

The list of potential vulnerabilities is open-ended and increases with every piece of hardware or software that is added to asystem, complete protection is not a realisticgoal.

As there is no perfect security anyway, it hasbecome common practice to try to reduce theoverall risks to an acceptable level.


6/28

Contd..

To reduce risks we need to perform a risk assessment before we can decide how muchand what needs to be done.

In simplest definition risk is a product of twofactors: probability of the occurrence of violation and the estimated damage causedby this event.


7/28

Contd..

The probability of occurrence is a function of our systems vulnerabilities and the attackersresources.

The potential damage is a function of thevalue of our assests.

Eg: If we have a complex system with weakprotections and a resourceful enemy, then theprobability of a successful attack is high.


8/28

Understanding EJB Security

The are two security measures that clientsmust pass when we add security to an EJBsystem: authentication and authorization.

Authentication must be performed before anyEJB method is called.

Authorization on the other hand occurs at thebeginning of each EJB method call.


9/28

Authorization in EJB

After the client has been authenticated, itmust pass an authentication test to callmethods on our beans.

The EJB container enforces authorization bydefining security policies for our beans.


10/28

Contd..

There are two ways to perform authorizationwith EJB:

With programmatic authorization , we canhard-code security checks into our bean code.

Our business logic is interlaced with securitychecks.

With declarative authorization, the containerperforms all authorization checks for us.


11/28

Contd..

We declare how we would like authorizationto be achieved through the deploymentdescriptor, and the container generates allnecessary security checks.

We are effectively delegating theauthorization to the EJB container.


12/28

Security Roles

A security role is a collection of clientidentities.

For a client to be authorized to perform anoperation its security identity must be incorrect security role for that operation.

The EJB deployer is responsible for associatingthe identities with the correct security rolesafter we write our beans.


13/28

Contd..

Specifying security roles in EJB is applicationserver-specific but should not affect theportability of our code.

Security Role Valid Identifier

Employees EmployeeA, EmployeeBManagers ManagerA

Administrators AdminA


14/28

Programmatic Authorization

To perform programmatic authorization threesteps 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.


15/28

Declarative Authorization

The primary difference between the twomodels is that with declarative authorization,we declare our beans authorizationrequirements in our deployment descriptor.

The container enforces these requirements atruntime.

To perform declarative authorization we haveto follow two steps.


16/28

Contd..

Step1: Declare Method Permissions.

Step2: Declare security roles.


17/28

Secure Interoperability

Secure interoperability means that EJB containersfrom different vendors cooperate in protectingEJB 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 theinvocation and the propagation of the principalinformation to the other.


18/28

Contd..

Any security information that needs to beexchanged must be standardized.

Otherwise one vendor product would not beable to understand the information sent by itscolleague on the other end of the wire.

The general protocol that EJB specificationrequires for interoperability is RMI-IIOP.


19/28

Contd..

For additional security-related interoperabilitythe EJB specification leverages two moreprotocols that were originally designed for

CORBA. IIOP/SSL : for authentication, integrity and

confidentiality.

CSIv2 (Common Secure InteroperabilityVersion 2): for additional authenticationcapabilities and principal propagation.


20/28

IIOP/SSL

SSL/TLS takes care of all the details of settingup secure transports between endpoints.

The deployers has to just provide the propercredentials that SSL/TLS can use during itsinitial handshake.

Internally the hosting EJB containers CORBA

Object Request Broker(ORB) is equipped toinsert SSL-level transport information intoEJBObject references.


21/28

Contd..

For IIOP/SSL these references take the formatof CORBA Interoperable ObjectReferences(IORs), and SSL/TLS-related

information is stored in the IOR as taggedcomponents. The receiving containers ORB recognizes the

IOP and its tagged components and henceknows how to let the SSL/TLS layer opentransport connections.


22/28

Disadvantage

SSL/TLS is not suitable for all securityproblems.

It does offers interoperable, standardized

means for mutual authentication betweencommunicating peers, but it requires publickey certificates in X.509 format to do this.

Moreover, SSL/TLS is heavyweight in the sensethat the initial handshake required to set up asecure transport adds a significant overhead.


23/28

CSIv2 CSIv2 was specified for CORBA by the Object

Management Group (OMG) in 1999 as asuccessor to earlier secure interoperabilityprotocols.

CSIv2 was designed to be used together withtransport-level SSL security and to complement it.

The Security Attribute Service(SAS) protocol inCSIv2 defines additional client authenticationfunctionality that is independent of SSL/TLS andcan be used with kerberos or UseId/passwordschemes.


24/28

Target authentication is not supported in SASprotocol so if mutual authentication isrequired, the SAS protocol must be combinedwith the transport-level target authenticationoffered by SSL/TLS.

The CSIv2 protocol also supports identity assertions as a means of principalpropagation.


25/28

Contd..

An identity assertion is sent by the callingclient to tell the receiver that it should notconsider the client identity for makingauthorization decisions, but the assertedidentity instead.

An asserted identity is much like a run-as

statement or a set-uid bit in the UNIX filesystem.


26/28

Contd..

With identity assertions a single method callmay have three different identities associatedwith it.

The transport-level identity as established bySSL.

An additional client identity establishedthrough SAS client authentication

The asserted identity.


27/28

Contd..

Identity Assertion

Client Authentication

Client AuthenticationMessage ProtectionTarget Authentication

Security attribute layer

Client authentication layer

Transport layer(SSL/TLS)


28/28

Thank you

security and interoperability services

Documents