Web Services Discovery in Secure Collaboration Environments

1. Web Services Discovery in Secure Collaboration Environments Mohamed Shehab Kamal Bhattacharya Arif Ghafoor

2. Introduction • Enterprises today are moving toward horizontal integration • Multidomain application environments where distributed domains interoperate with each other is a reality in Web-services-based infrastructure • Collaboration enables domains to effectively share resources; however, it introduces several security and privacy challenges • Trusted mediator did not solve the isues • In this article, the authors • Use the current web service standards such as SOAP and UDDI to enable secure interoperability in a service-oriented mediator-free environment • Consider a multidomain system where each domain provides a set of Web services. • Propose a mechanism to allow for both secure interoperability and service discovery in a mediator-free multidomain Web-service-based system.

3. Health Care System Example

4. Health Care System Example • The edges between hospitals signify the established service collaborations. • Using these collaboration agreements, physicians in Ohio (Hospital A) are able to acquire services in Minnesota (Hospital B). • Using a combination of such collaborations enables physicians in Ohio to acquire services in California (Hospital D). • When a patient from California moves to Ohio, • The collaborations would enable doctors in Ohio to acquire authorizations to access services in California and retrieve the patient’s records

5. Article’s Contributions • Three main contributions • Propose a multihop SOAP-based messaging protocol • Propose an authentication mechanism • Propose a service discovery protocol

6. Role-Based Access Control • All collaboration domains have adopted RABC as their access control policies • In RBAC, permissions are associated with roles • In the hospital example, the doctor role dominates the nurse role • Cross-domain mappings is used for the collaboration among domains • Those mappings will be referred to as cross-links • Cross links are between the same domain and different domains • Domain administrators should agree on • Cross links selections • Restricted Access

7. Mediator Free Collaboration • Secure interoperability should ensure two principles. • The principle of autonomy, • The principle of security • Use a central trusted third party SOLUTION • A mediator-free collaboration • A completely distributed form of cooperation • none of the collaborating domains has a global view of all the access control policies • There is no central trusted third-party • Domains dynamically access control decisions • Domains will use the access path discovery

8. SOAPSimple Object Access Protocol • XML-based messaging protocol • Not tied to any particular transport protocol, operating system, or programming language • Three parts message : an envelope, header data, and a message body Access Path Discovery • Neighboring domains connect via cross-links • No immediate links, crate a secure access path • Collaboration between intermediate domains

9. Path Authentication • SOAP messages propagate until source is found • A secure path mechanism is needed • SOAP ={Header , Body} = > Header ={Signature} • Signature = sign(h(Body ), e ) => h() is a secure one-way hash function => private key e, public key d • Signature cannot be forged • Verify signature => h(Bodyj) = sign(Signature j , d j) for all 0 ≤ j ≤ i.

10. Security Attacks • Path Corruption attack • Path insertion attack : attempt to insert a new domain in the access path • Inability to generate a signature • Requires knowledge of the private key • Path deletion attack : attempt to delete a domain in the access path • Cannot generate a signature • Path cannot be authenticated • Path replay attack : malicious domain will try to capture a request and reply to it • Attacker not able to alter information in the SOAP body • Colluding domains attack : two domains will collude and forge a new access path • Conspiring domains are not able to generate a fake signature.

11. Service discovery and UDDI • Service discovery is an important component of Web service architectures • Services are discovered by querying the public UDDI registry • A private UDDI infrastructure in which each domain maintains a private UDDI registry • Service discovery is closely tied to the access path discovery • A Domain should have sufficient authorizations to access the UDDI registry of the next domain • Authorizations are acquired by building access paths to roles in other domains • To discover a service, domains should disclose paths to those roles • Service discovery requests are sent using the same SOAP encapsulation

12. UDDI Registries

13. Steps • Steps 1–2. A service discovery arrives at a domain • Verify the request signatures (pass or drop) • Extract the encapsulated access path • Step 3. Check that the access secure with respect to the path-linking rules, Forward the service request and assigned access role to the request evaluation module. • Step 4. The request evaluation module queries • the private UDDI registry to discover services according to the service request criteria. • the access control policy to find the set of services assigned to the role -> Srq • The private UDDI returns a set of service identifiers ->Sc. • The request evaluation module computes the join between the sets of services Sc and Srq -> Sresult = Sc ∩ Srq . • Steps 5–6. • If the set Sresult is empty, the request is updated and forwarded to neighboring domains • Otherwise, the domains send a reply to the querying domain indicating the access path and path signature

14. Number of Domains Effects

15. P maxNeighborhood Probability