Venki1010.Conference - Copy

8/2/2019 Venki1010.Conference - Copy

http://slidepdf.com/reader/full/venki1010conference-copy 1/8

Incorporating Pre Audit Method in Multilevel Secure Composite

Web Services

P.VENKATESH1 N.H.VASU DEVAN2

Dr.Pauls Engineering College Dr.Pauls Engineering College

[email protected] [email protected]

S.RAJESH, M.Tech(MBA)3 P.KUMARAN, M.E4

[email protected] [email protected]

ABSTRACT E-commerce, e-banking, and

stock markets are important domain and

have more competite in their market and

provide the better services to the customer

with secure and efficient manner. Web

services play a vital role in order to achieve

the better services to the service

consumers .can access the information

through internet. Application based on the

Service-Oriented Architecture (SOA)

consists of an assembly of services, which is

referred to as a composite service which

uses by Banks, Military and Defense

systems. A composite service can be

implemented from other composite services,

and hence, the application could have a

recursive structure. Incorporating a security

policy for a composite service is not easy because the policy should be consistent with

the policies of the external services invoked

in the composite process. Web services uses

XACML language for providing the security

to the web services, but it still suffers from

some limitations when it comes to its

capabilities in supporting the requirements

of open Web-based systems. But our

approach incorporate the access control

modularity(Pre auditing method) for each

user which defined in XACML and lead to

EEXACML specification.

1. INTRODUCTION

Web services technologies change the

software industry drastically by developing

and integrating enterprise web services and

application in order to enable the user to

access them.web services combination is the

merging of web serviecs from differences

service providers to create a ,more

sophisticated value added web services to

the user users .Researchers put on efforts to

bring out the state of the art in web servies

technologies and security technologies for

web services .Securing an SOA application

is an important requirement for all the

domains besides the functional requirement.

2.POLICY OF COMPOSITE SERVICES

mailto:[email protected]











This paper starts with a simplified composite

service application to explain our approach

rather than the WS-I SCM application. Thetravel reservation service shown in Fig. 1 is

a composite service that consists of a

process invoking the airline reservationservice and a hotel reservation service,

which are external services. These external

services are invoked in parallel andsymmetrically in the process of making the

reservation for a trip. The external services

may also be composite services that invoke

other external services.A composite service process that invokes external services can be

represented using BPEL [1]. Listing 1 in

Fig. 2 showsa simple composite process

expressed in BPEL and a correspondingdiagram generated by a tool such as

Eclipsefor BPEL [6] or Web SphereIntegration Developer [7].

Access Control Policy

The Access Control Policy restricts who can

access a service.For example, only travelagency employees should invokethe travel

reservation service. This requirement is for aservice operation itself. Therefore, an ACP

is a set of an operation name and a list of

roles that are allowed to access thatoperation. The ACP can be defined as

follows: ACP :¼(operation name, role list).

The ACP for the operation getReservation of

the travel reservation service can be defined

as (getReservation, [agencyEmp]), whereagencyEmp is a role for a travel agency

employee.There are several XML formats

for ACP representation, such as XACML [5]and WS-Policy. XACML is a typical

specification for an access control policy, or

we could use WS-Policy for ACP. However both specify only a framework for policy

representation, and hence we need to add

some extensions to express the ACP for a

service itself. There is no standardizedexpression of ACP for Web Services, while

WS Security Policy is the standard for MPP

policy, so the representation of the ACP is

not discussed here. In this study, defininghow to express of the ACP is not our focus.

3. MPP Transformation

MPP predicates are transformed from theWS-Security Policy representation. The

WS-Security Policy specification defines

many security policy assertions to specify

security requirements. However, byconsidering the security requirements

specified by WS-Security, the assertions of

WS-SecurityPolicy can be classified into thethree types: for integrity, for confidentiality,

and for optional requirements. We define the

MPP predicates that correspond to thesetypes. The predicate for an MPP is mpp,

which is applied to a message m and has ID

lists for the three security requirements andtokens. The integrity requirement is

specified by a signature predicate, where

sigId is the ID of this signature on a variablein a variable list var, and the tokenId is the

ID of a security token used for this

signature, using the canonicalization

algorithm calgo, the signature algorithmsalgo, the transform algorithm talgo, and the

digest algorithm dalgo. The last variable



protectToken of the predicate signature

specifies a Boolean value that flags a

security token to be self-signed if the tokenis used for message signature.This property

is specified by the ProtectTokens assertion,

and is a unique property for signatures.

4.BPEL Transformation

An element in BPEL is also transformed

into a predicate whose name is the same asthe element name. A sequence element of

the BPEL process is transformed into a

sequence predicate. The sequence predicateconsists of flows and actions. A flow

predicate specifies a linkage of BPEL

actions. We define some actions as predicates. The receive, invoke, reply, andassign predicates are transformed from the

corresponding actions. A variable

assignment in the composite process isspecified by an assign predicate, where the

specified variable assignment from the

fromvar variable of the from message is tothe tovar variable of the to message.The

variables in these predicates correspond to

the attributes of an XML element for each

action.

5. ACP Composition Rule

The ACP can be regarded as an data

property as same as MPP, so the composite

ACP will be valid when data for a compositeoperation and data for an atomic operation

are identical and their properties are

consistent. Listing 4 in Fig. 7 shows the

predicates for ACP composition rules. The predicate for ACP is quite similar as the

MPP’s predicate because both rules are

based on the same basic idea. Therequest.ACPInconsistents predicate is a

constraint for consistency of roles allowed to

access an operation at request side. This predicate returns false if a request-side

security policy named cPolName for

composite service has no inconsistent roles.

And true is returned if a validated policyviolates ACP consistency rules by a variable

in the composite service cVar, and provides

information for an invalid requirement

eCode and solution hints sol to resolve theinconsistency, as same as the MPP

predicate. The requestRoleInconsistent predicate returns false if there is no invalid

roles in a security policy cPolName for a

composite operation cOpe. The predicate

requestRole signifies that the atomic serviceoperation aOpe is allowed for the roles

specified in aRoles. The composite and

atomic ACPs are consistent if the rolesallowed by aOpe are included in the roles

allowed by cOpe. The predicate

inconsistentRole returns true when all of theroles in aRoles are included in the allowed

roles cRoles. The predicate

requestACPInconsistents returns false if thecomposite and atomic ACPs are consistent.

When true is returned, we can redefine the

consistent ACP by referring a

counterexample. We define the constraintson policy consistency as rules to validate the

composite MPP and ACP. return false when

a composite policy satisfies the validcomposition rule, hence we can pinpoint

inconsistent portions of composite policy

when the rules are violated and return true.Thanks to the way inference works, our

engine can work for both the top-down and

bottom-up policy composition approaches.

The consistent composite policies are



inferred using the bottom-up approach, and

the composite policies can be verified using

the top-down policy definition approach.Also, we can compose policies using the

same predicates even if external services are

also composite services, not atomic service.

Solutions for Policy Inconsistencies

Our policy composition engine finds where

policy inconsistencies exist according to the

declarative rules defined in Section 4.3.

However, the inference engine cannot gethow to fix the inconsistencies. Not only

finding inconsistency problems but also

providing solutions are quite important

practically. Actually, multiple solutionswould be possible for one inconsistency

problem, therefore, we list invalid cases thatcause policy inconsistencies and provide

typical solutions for each invalid case. We

clarify the definition of policy consistencyused in this paper. If all consistent

requirements to an atomic policy are

included in a composite policy, the

composite policy is consistent to the atomic policy. Fig. 8 illustrates relevance of atomic

and composite policies. Our definition of composite policy consistency is shown byFig. 8a. Hence, we should fulfill the

relationship shown in Fig. 8a by changing an

atomic and a composite policies if we findinconsistent requirements by inconsistency

inference. We have two approaches to fulfill

the policy consistency: changing a

composite policy, or changing an atomic policy. Here, this paper takes the first

approach, i.e., changing a composite policy,

because the objective of this study iscreating a consistent composite policy from

atomic policies applied to atomic services

that consists of a composite service.Therefore, we assume that atomic policies

are predetermined and hard to revise, hence

we decide to take an approach of chaining acomposite policy in this work. There are

three types of reasons for inconsistencies we

assumed, as shown in Fig. 8: 1) a composite

policy lacks some requirements included inan atomic policy (Fig. 8b), 2) an atomic

policy has larger number of requirements

than those of composite policy, but acomposite policy has also additional

requirements which are not included in the

atomic policy (Fig), and 3) a composite policy has larger number of requirements

than those of atomic policy, and also a

atomic policy has also additional

requirements which are not included in thecomposite policy (Fig). Our composition

engine provides solution hints and suggests

how to fix inconsistencies of atomic and

composite policies, it means that the invalidrelations in Figs. 8b-d change to the valid

relation in Fig. 8a by provided solutions, for example, adding some missing

requirements. The following sections

discuss solutions to create a consistent

composite policy.

5.1Solutions for MPP Inconsistent

The requestMPPInconsistent predicate

becomes true when one of the three

following predicates is true, requestIntegrityInconsistent, Request

Confidentiality Inconsistent, and

requestOptReqInconsistent predicates. Herewe discuss the solutions for the integrity



inconsistencies only because the space is

limited. The request IntegrityInconsistent

predicate has three possible invalid cases: 1)Algorithm inconsistent, 2) Token

inconsistent, and 3) ProtectTokens

inconsistent. Solutions for theseinconsistencies are discussed in the

following.Here we represent these solutions

logically.Algorithm inconsistent. If analgorithm for atomic variables and an

algorithm for composite variables are

inconsistent, an algorithm for composite

variables needs to be changed to another consistent algorithm with an atomic

algorithm. If the following inconsistent

predicates returns true, two algorithms

specified by variables are inconsistent,hence an algorithm for a composite service

needs to be changed to the consistent one of an atomic service. The change CompAlgo

predicate means that an algorithm cCalgo

for a composite service is changed to a new

one nCalgo. This is consistent with analgorithm aCalgo of an atomic service,

which represents the consistent predicate. A

signature requires four algorithms, acanonicalization algorithm, a signature

algorithm, a transformation algorithm, and a

digest algorithm. The following inconsistent predicates correspond to the

canonicalization algorithms.The other three

predicates for other algorithms are omitteddue to the space limitation..

5.2Token inconsistent.

If signing security token types are

inconsistent, a new signature whose signing

token type is aTtype needs to be added to acomposite policy. There are two cases of

token inconsistent as follows.The

inconsistent predicate returns true when atoken type for atomic service aTtype and for

composite service cTtype is inconsistent.

And the exist predicate returns true if acomposite policy cPolName specifies a

security token which type is aTtype. When

both predicates are true, a signature that uses

a token whose type is aTtype needs to beadded, where the addSignature predicate

represents this rule. In the second case, the

inconsistent predicate returns true, but theexist predicate is false. Therefore, a new

security token whose type is aType needs to

be added, as represented by the addToken predicate. And then a new signature which

uses a new aType token is also added.

inconsistent(aTtype:TokenType,

cTtype:TokenType),

exist(cPolName:String,aTtype:TokenType) !

addSignature(cPolName:String,

aTtype:TokenType)

inconsistent(aTtype:TokenType,

cTtype:TokenType),

not(exist(cPolName:String,

aTtype:TokenType)) !

addToken(cPolName:String,

aTtype:TokenType),

addSignature(cPolName:String,

aTtype:TokenType)

Top-Down Policy Composition

In the top-down approach, security policies

for a composite service is also necessary toinput the policy composition engine. The

following is representations for security

requirements of a composite service, i.e.,



Travel Reservation Service. _ MPP

for TR

signature(agencyMpp, ‘agp:sigID1’,

[soapBODY],

‘agp:x509ID’, exc14n, hmacsha1, exc14n,

sha1, true).

encryption(agencyMpp, ‘agp:encID1’,

[soapBODY],

‘agp:x509ID’, kwrsa15, aes256).

token(agencyMpp, ‘agp:x509ID’, x509V3).

supportingToken(agencyMpp, ‘agp:unID’,

username).

_ ACP for TR

available(agencyAcp,

‘agp:getReservation’).

acp(agencyAcp, [agent, airlineEmployee]).

These predicates represent security

requirements on a request message of the

travel reservation service. This security policy requires both signature and

encryption on a SOAP Body. Here, the

soapBODY keyword means that a SOAP

Body of the message should be covered by

signature or encryption. Both signature andencryption require an X509v3 security

token. Additionally, another security tokenis required: a username token as a

supporting security token.

5.3 Bottom-Up Policy Composition

In the case of bottom-up approach, atomic

services have attached security policies but

no security policy for composite service aredefined. Therefore, we apply the template of

composite policy in the logic representation

with variables as shown below instead of the policy for travel reservation service in

Section

_ MPP template

signature(agencyMpp, SigID,

SignedPartsList, SigTokenID, C14NM,

SigM,

TransM, DigM, PToken).

encryption(agencyMpp, EncID,

EncryptedPartsList,

EncTokenID, KEncM, DEncM).

token(agencyMpp, SigTokenID, STType).

token(agencyMpp, EncTokenID, ETType).

supportingToken(agencyMpp,

AddTokenID,

ATType).

_ ACP template

available(agencyAcp, Operation).

acp(agencyAcp, RoleList).

role(RoleName).

To infer values for variables in the policy

templates, we need to execute the

requestDPPInconsistent andrequestACPInconsistent with a composite

policy name agencyMpp. Multiple values



which satisfy the policy consistency rules

are obtained. The following is one example

of results for the DPP. It means that thecomposite policy should have a signature by

the exc14n algorithm for canonicalization.

CompOpe = ‘agp:getReservation’,

CompVar = ‘agp:hotelInfo’,

AtomOpe = ‘hpi:reserveRoom’,

AtomVar = ‘hpi:hotelInfo’,

TCODE = 1,

ECODE = 1,

Sol = [C14NM, exc14n]

We need to create the concrete composite

policy which includes all of the inferredvalues. We propose the supporting method

for policy generation as discussed in Section

6. PERFORMANCE EVALUATION

We apply our policy composition to the WS-I SCM application explained in Section 2.

The Retailer service can be regarded as a

composite service that invokes the

Warehouse A, B, C services. TheWarehouse A, B, C services also invoke the

Manufacturer and Warehouse Callback

services, and they are also regarded ascomposite services. The WS-I defines the

MPPs for each service in the SCM

application, so we evaluate our approach by

applying to the application in the top-downway. We examined the execution time of the

requestMPPInconsistencies predicate that

infers all inconsistent requirements, number of logical inferences, and the average

number of lips (logical inferences per

second). The environment of this experimentis as follows: the operating system is

Windows XP -Professional with Service

Pack 2 running on an Intel Core2 2.00 GHz

with 3 GB of memory. We found sixinconsistencies for the SCM application, and

the results of experiment are .

• Execution time: 50 [milli seconds].

• Number of inferences: 116,718.

• Average number of lips: 2,489,984

[Lips].

Comparing the policy composition in our approach, we tried to find the

inconsistencies of the SCM application

according our consistency rule manually.We needed to check multiple input files in

XML, i.e., 22 files related to WSDL, 24 filesfor BPEL, 6 files for security requirements,and it was quite hard only to find the

relations by assign actions. We can find the

assign action in BPEL soon, however we

need to check the corresponding WSDL andsecurity requirements to extract data

properties. Actually, we needed more than

one hour to find the data properties fromXML representations, and also it took more

times to check consistencies of the data

properties, about a half hour additionally.Above the experimental results,

our policy composition framework shows

significant improvement in terms of

reduction of time and costs, so it would begreat help to finding the policy

inconsistencies.



7. CONCLUSION

This Proposed system will validate the user

access control for enforce the goals of

information Security. XACML will be

robust when incorporate the pre audit

method in XACML specifications. It

reduces the false alarm rate and will be

efficient in order to avoid application

layered attacks. The advantage of our

approach is that the policy consistency rule

does not depend on any specific processes.

And two composition approaches can be

supported; top-down and bottom-up policy

composition, providing solution hints to

resolve policy inconsistencies. We also

discussed how to create a consistent policy

semi-automatically from solution hints.

Documents

Venki1010.Conference - Copy