Distributed Coalition Registry for Dynamic CoalitionsDistributed Coalition Registry for Dynamic Coalitions
Masters Project Report
Student: Shilpa AthaniUIN: 00110940
Email: [email protected]
Advisor: Dr. Ravi MukkamalaEmail: [email protected]
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
Recommended