Distributed Coalition Registry for Dynamic CoalitionsDistributed Coalition Registry for Dynamic Coalitions

Masters Project Report

Student: Shilpa AthaniUIN: 00110940

Email: sathani@cs.odu.edu

Advisor: Dr. Ravi MukkamalaEmail: mukka@cs.odu.edu

Project Defense Date: 31st July 2006

1

Table of Contents

1. Abstract………………………………….…………………………………………….. 3

2. Problem definition………………………………….…………………………………. 4

2.1 Resource Sharing………………………………….…………………………. 4

2.2 Distributed Dynamic Coalitions……………………………………………... 4

2.3 Access Control policies………………………………………………………..5

3. Proposed Solution………………………………….………………………………….. 6

3.1 Distributed Coalition Service Registry (DCSR) …………………………….. 6

3.2 Access Control Policies for Services………………………………………….6

3.3 Implementing Credential file for every user…………………………………..7

4. DCSR Architecture………………………………….………………………………… 8

5. DCSR Design………………………………….………………………………………. 9

5.1 Goals………………………………….……………………………………… 9

5.2 Design Diagram………………………………….………………………..... 11

5.3 Functions………………………………….……………………………….... 12

6. System Implementation………………………………….…………………………... 16

6.1 Service Oriented Architecture……………..…………………………………16

6.2 The Advantages of Using Web Services………………………………….…16

6.3 Technologies used………………………………………….………………..18

6.4 Access Control Policies…………………………..………………………….19

6.5 Credential Based Approach………………………………………………….21

8. Screen shots & Walk through……………………………………………...………… 22

9. Conclusion & Future Work…………………………………………………..……… 35

10. References………………………………………………………………………….. 36

2

1. Abstract

Different organizations, in a common scenario, come together to form a coalition. The

main reason for this is to share resources among themselves. The coalition is formed

without prior planning to accomplish certain tasks. The organization that provides the

service is called as service provider organization. If there was a single organization it

would have been easy to share resources. But when more than one organization comes

together it’s a challenge to establish resource sharing. And if availability of the coalition

registry is taken into consideration then the solution to the above problem is a Distributed

Coalition Service Registry.

The project focuses on establishing a Distributed Coalition Registry to cater to the needs

of organizations located in different places. Distributed registry also provides numerous

advantages to the organization that come together. Further the purpose is to restrict the

access to the services based on the credentials of the user that logs into the organization

website. Here there will be a specific rules which apply as to who should be able to

access the service offered by the service provider organization. The organization that uses

or requests the service from other organization is called a service requester organization.

These features also help service registry not only to act as a repository but also to share

resources in a proper way among the organizations. An authorized user with proper

credentials will only be able to make use of the services of the service provider.

The project is built using C#.NET and Microsoft SQL Server. The whole application is

built on a service oriented approach.

3

2. Problem Definition

2.1 Resource Sharing

Resource sharing is a scenario in which two organizations share their resources

with each other. Resource sharing among organization is taking and giving of

resources. Resource can be available either locally or remotely to any

organization. Making the resource available to another organization is a real

challenge in itself. Whenever a resource is being shared in a distributed network

providing access to the resource should be controlled by some policies. The user

can authenticated only through proper username and password. One of the main

factor affecting the resource sharing is that there is should be a proper

authenticated access to the available resource.

2.2 Distributed Dynamic Coalitions

Having a single centralized coalition registry is not that a great thing. Making it

distributed so that compromise of one coalition does not affect the functioning of

resource sharing process is a great challenge. When a coalition is formed all the

organizations come together to share their resources. If this coalition is damaged

or compromised due to any natural calamity or unknown error then it results in

the non availability of resources. This is the reason why the proposal of

distributed dynamic coalitions. Another challenge that can arise in implementing

the distributed DCSR is that when one transaction is being copied to another

database through interprocess communication there should not be looping among

the databases.

4

2.3 Access Control Policies

In a coalition even after taking precautions of creating username and password

and securing the access to the resources some hackers might try to make use of

the resources by illegal means. This should not be allowed. There should be a

second level of security to protect the unauthorized use of the resources. This can

be achieved through creating access control policies for each of the service. By

doing so only the authorized person can access the services offered by the service

provider organization.

For example consider a document which only the president of the

company is allowed to open. This document can be a financial folder or financial

document that only the president of the company is allowed to see. By creating a

access control policy such that only the person with designation president is

allowed to see we can limit the access to the document.

5

3. Proposed Solution

3.1 Distributed Coalition Service Registry (DCSR)

The coalition Service Registry is a distributed one. By making this as

distributed it is made available to the organizations at all times. If there was a central

service registry then the compromise of the service registry would lead to the

damage/loss of data. The coalition service registry is made to act as a proxy. This masks

all the differences in a heterogeneous environment. The CSR can be extended further to

provide services like authentication. Only the users that are authorized are allowed to

query the DCSR. The other challenge of avoiding looping while copying the transactions

is by creating an xml file in which the links of the other database names are provided.

The DCSR acts like a bridge or a proxy between the organizations and by doing there

exist some trust among the organizations. Any organization which has to be in a coalition

has to register itself with the DCSR to host its services to be provided.

3.2 Access Control Policies for Services

Sometimes there arises a situation where an unauthorized user gets into the system and

tries to make illegal use of the services. There is always the first level of security which is

the username and password authentication. But by specifying the access control policy

for a service there will be a level of restriction applied on the service which will prohibit

unauthorized use of the service. The different tags that are being used for a access file are

age, experience, designation, salary etc which can help in targeting the service to a

certain group of users.

6

3.3 Implementing Credential file for every user

A credential file is one which specifies some criteria for every

user. For example a user might be a person with certain age, certain designation and

experience. This set of criteria will make a general group of users who can be allowed

to given access to a particular service. A credential file is an xml file which has the

values for different tags such as age, experience, designation etc.

7

4. DCSR Architecture

There are two levels in the above specified architecture. They are coalition level and the

DCSR level. The coalition level is an interface with itself. It interacts with other

coalitions. Requests and responses take place in this module. It ensures the authenticity of

the coalitions which are sending the requests. The local user interface provides the user

with an interface and is responsible for serving the request.

8

5. DCSR Design

5.1 GoalsThe DCSR design is based on the following roles.

Customizability

Different coalitions will want to do the authentication at the DCSR level

and some would want to do it at the coalition level. Even the routing can

be done either through DCSR or through organizations. Right now the

implementation is done through the organizations. The organizations

match the policy file and the credential file and the user can see only the

services which he/she is authorized to see based on the credential file.

Extendibility

Any new additional feature can be added to the present system. The design

is such a way that addition/deletion of a functionality will not affect the

system.

Scalability

At any instant the number of coalitions can be small or large. Any number

of coalitions can be added to the present system.

Security

As the size of the coalitions increase there occurs a stage where the

authentication level goes down. Therefore the username/password

authentication is provided.

9

Performance

The design should be such a way that it provides good performance. Good

performance is in terms of low overhead, increased throughput and

response time.

10

5.2 Design Diagram

The above design diagram shows a cloud of distributed DCSRs. Each of the DCSR has a

database of it own. The organizations communicate with one of the DCSRs and this

transaction is being replicated in all the other DCSRs. The replication of the DCRS is

implemented through a mirror file which is an xml file and which the DCSRs list that has

to be contacted to replicate the transaction.

For example any transaction being written to the database of DCSR-A, there exists a

DCSR mirror xml file which will have the links to the DCSR-B and DCSR-C. Similarly

when any transaction is being copied to DCSR-B, it contacts DCSR-A and DCSR-C and

the process will be replicated. Precaution has been taken such that there will not be any

11

looping among the DCSRs which will result in continuous communication among the

DCSRs and may end up in an infinite loop.

5.3 DCSR Functions

DCSR provides the following functions

Registration

Whenever a coalition member intends to share its local services, the

registration function is being used. The admin of service provider

organization registers with the DCSR and creates the access control policy

and registers this access control policy file with the DCSR. Even at the

service requester’s end the administrator of the organization has to register

with the DCSR to use the service provided by the service provider.

Authentication

Every user that wants to use the service provided by the service provider

organization has to have a username and password account to access the

services. The administrator of the organization specifies on this username

a credential file which will then filter out the services that are available to

the user.

Authorization

This function decides on what services are allowed for which user to be

used or executed. Based on the credential file this access is given to the

user. This is a credential-based authorization in which the authorization

policies are specified in terms of policies at service-level.

12

Query Processing

This function identifies whether a resource request can be met by a

registered service. This requires the resolution of policies at the service

level. This helps in determining which services are to me made available

to the specified user with given credentials.

Routing

This function helps to route the member service requests to the service

provider and sending back the reply to the requester. There are three

options for the DCSR to handle the service requests.

i) DCSR as a registry

DCSR simply acts as a service registry and nothing more. Hence, it

has no role to play for a service access request from a member. In the case

where a member registers a service proxy with DCSR, it could send the

proxy to the requester

13

ii) DCSR as token generator

DCSR receives the service request and generates a token to be submitted

to the service provider. Under this option, DCSR is also acting as a trusted third party.

The steps under this role are as follows.

(i) Authenticate the requesting organization.

(ii) Extract the requester credentials from the request.

(iii) Check the coalition policy as well as WS-policy of the service being requested for

acceptance of the service request.

(iv)If all checks are successful, generate a token with the submitted credentials.

(v) The token is sent to the requester along with the generated shared key.

14

iii) DCSR as interface to coalition members

Once the requester receives the token, it can directly establish a

connection with the service provides and get services using the token. Under the

third role (Figure 2c), DCSR does it all. In particular, it follows the following

steps.

(i) Authenticate the requesting organization.

(ii) Extract the requester credentials from the request (e.g., decrypt the message; verify

the digital signature, etc.).

(iii) Check the coalition policy as well as service policy of the service being requested for

acceptance of the service request.

(iv) Invoke the services at the service provider (using whatever agreed upon protocol),

submitting the requester credentials.

(v) Receive result/reply from the service provider.

(vi) Forward the result/reply to the requester.

15

6. System Implementation

6.1 Service Oriented Architecture

The entire system is implemented using service oriented approach. SOD

his advantageous such that it helps using the software components to be

reused. This is because of the loose coupling that exists among the

software components. It has the following characteristics:

XML is the enabling technology for SOD, since they're platform-independent

standards.

Consumers can dynamically discover services.

Services are interoperable.

Benefits of service oriented architecture:

Code mobility

Easier implementation of security

Better maintainability Better scalabilityBetter parallelism in development

6.2 Advantages of using Web Services

Interoperability: This is one of the most important benefits. Web services work

outside of private networks. Therefore they can be used with many different

technologies; Web services do not become obsolete. Developing them is cost-

effective compared to developing individual technology-based solutions. Web

services allow developers to use various programming languages, such as: Java,

16

C++, and VBScript. Additionally Web services are virtually platform-

independent.

Reusability — Web services minimize the need for application specific

deployment code. This leads to the situation where the Web services can be

reused.

Usability — Web services allow the business logic of many different systems to

be exposed over the Web. This gives leads to the freedom to use the Web

services. Instead of re-writing the whole for each client, including additional

application-specific business logic in the client-side is enough. This allows you to

develop services and/or client-side code using the languages and tools of your

choice.

Deployable nature — Web services can be deployed over standard Internet

technologies, even over a firewall. Due to the use of existing standards,

underlying security is already built-in.

Reliability — Web Services are very reliable and can be used without the fear of

losing data or connection.

17

6.3 Technologies Used

Presentation Layer: ASP.NET, CSS

Business Objects: C#, ADO.NET

Database: Microsoft SQL Server 2000

Web Server: IIS 6.0 on Microsoft Windows 2000 Server

Security Protocols: WSE 3.06.4 Access Control PoliciesWhen an organization

allows sharing of resources it must ensure that its own security policies are

adhered to. The main idea is to allow users external to the organization access to

the resources of the organization from the service provider if and only if the user

possess certain attributes similar to those possessed by internal users. The

criterion for such a method is being specified in the access control policy file.

Then such a access control policy will be mapped with a credential file and the

access is given to the user to a particular service only if he/she has those

criterion.Sample Access Control Policy File:

18

6.5

Credential Based ApproachIn a dynamic coalition environment users of an

organization need to gain access quickly to the resources of service provider

organization in order to perform the task at hand. At such cases a credential file

which is an xml file is specified by the administrator of the organization. The

advantage of the administrator creating such a file is the access to the services can

be controlled and unauthorized use can be avoided.Sample Credential file:

19

Screenshots &

Walkthrough

Organization 1: Dell

1) Administrator of Dell creates the access policy file from the admin interface

20

Select the option “Create Policy” from the menu

21

22

23

24

Sample Access Control File:

25

2) Administrator registers the organization in DCSR with the appropriate policy file:

Snapshot of the database:

26

3) Registration of the service of the Organization Dell by the administrator:

27

Snapshot of database

4) Registration of the service requester organization2 . Example IBM

Database Snapshot of the registration

28

5) Creation of Credential file by the admin of the Organization 2 IBM

29

Credential.xml file created:

30

6) User of the organization 2 IBM logs in:

When the user is authenticated gets the following page where he/she can view the global services he is eligible to execute:

31

Entering values to execute the service of adding vector array:

Execution of add service:

Similarly for mul service:

32

33

7. Conclusion & Future Work

In this project the communication between the organizations and the DCSR is assumed to

be trusted. This is called as trusted coalitions. In the previous system if the user level is

malicious or compromised the whole system would have failed. To this problem or

situation that might have aroused this developed prototype takes care of the situation by

creating the access control policies for the services. In an access control policy file a

policy is mentioned for each service. There are tags that being created that specify or also

to say in a broader sense see to that there is no unauthorized access to the service by an

external user.

In this project a credential file is created by the administrator of service requester

organization. The credential file is created on the lines of the access policy file. There is

always an option for future work to extend this file to implement the hierarchy for the

designation tag. This leads to a scene where generic designation levels can be maintained.

This prototype implements the designation tag assuming that a common scheme of levels

is being followed in all the organizations.

Resource sharing is a very important feature where different organizations can come

together and share their resources. If such a technique is done in a distributed

environment it provides availability and fast response times. The access control policies

and the credential file can be improved based on a hierarchy of designations.

34

9. References

1. R.Mukkamala, V. Atluri, J. Warmer and R.Abbadasari. A Distributed Coalition

Service Registry for Ad-hoc Dynamic Coalitions: A Service-oriented Approach

2. R.Mukkamala, V. Atluri and J. Warner. A Credential-based Approach for

Facilitating Automatic Resource Sharing among Ad-hoc Dynamic Coalitions.

35