Masters_Project_Report.doc
Upcoming SlideShare
Loading in...5
×
 

Masters_Project_Report.doc

on

  • 261 views

 

Statistics

Views

Total Views
261
Views on SlideShare
261
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Masters_Project_Report.doc Masters_Project_Report.doc Document Transcript

  • Distributed Coalition Registry for Dynamic Coalitions Masters Project Report Student: Shilpa Athani UIN: 00110940 Email: sathani@cs.odu.edu Advisor: Dr. Ravi Mukkamala Email: 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 4
  • database through interprocess communication there should not be looping among the databases. 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 6
  • age, experience, designation, salary etc which can help in targeting the service to a certain group of users. 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 8
  • the coalitions which are sending the requests. The local user interface provides the user with an interface and is responsible for serving the request. 5. DCSR Design 5.1 Goals The 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 9
  • As the size of the coalitions increase there occurs a stage where the authentication level goes down. Therefore the username/password authentication is provided. • 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 11
  • 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 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 12
  • user. This is a credential-based authorization in which the authorization policies are specified in terms of policies at service-level. • 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 scalability 16
  • • Better 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, 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. 17
  • • Reliability — Web Services are very reliable and can be used without the fear of losing data or connection. 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.0 18
  • 6.4 Access Control Policies When 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: 19
  • 20
  • 6.5 Credential Based Approach In 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: 21
  • 7. Screenshots & Walkthrough Organization 1: Dell 1) Administrator of Dell creates the access policy file from the admin interface Select the option “Create Policy” from the menu 22
  • 23
  • 24
  • 25
  • Sample Access Control File: 26
  • 2) Administrator registers the organization in DCSR with the appropriate policy file: Snapshot of the database: 27
  • 3) Registration of the service of the Organization Dell by the administrator: 28
  • Snapshot of database 4) Registration of the service requester organization2 . Example IBM Database Snapshot of the registration 29
  • 5) Creation of Credential file by the admin of the Organization 2 IBM 30
  • Credential.xml file created: 31
  • 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: 32
  • Entering values to execute the service of adding vector array: Execution of add service: Similarly for mul service: 33
  • 34
  • 8. 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. 35
  • 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. 36