security and interoperability services
TRANSCRIPT
-
8/2/2019 Security and Interoperability Services
1/28
Security and Interoperability
Services
-
8/2/2019 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).
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
16/28
Contd..
Step1: Declare Method Permissions.
Step2: Declare security roles.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
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.
-
8/2/2019 Security and Interoperability Services
27/28
Contd..
Identity Assertion
Client Authentication
Client AuthenticationMessage ProtectionTarget Authentication
Security attribute layer
Client authentication layer
Transport layer(SSL/TLS)
-
8/2/2019 Security and Interoperability Services
28/28
Thank you