Semantic Markup for Secure Survivable Enterprise Applications Anya Kim, Amit Khashnobish, Jim Luo, Bruce Montrose, Myong Kang US Naval Research Laboratory Code 5542 Washington, DC
Introduction • Service-oriented architectures – Relies on the ability to communicate relevant security information in a machine-understandable manner • Resources are protected by security mechanisms – Can act as barriers to access • Interoperability requires semantic markup of resources with security-related metadata – Enable dynamic discovery and invocation of services in a secure and trusted environment
Security in SOA Specification & Matchmaking Current Standard Our Contribution Enterprise Application Level BPEL Augment with T2 T4 security-related markup in the context of the T1 T3 T5 application Infrastructure UDDI Add semantic markup and query capabilities D1 D2 WSDL Semantic description of security-related concepts D3 D4 using ontologies Web-service Level
Security Specifications in SOA • More complex than functional descriptions – Security Requirements and Capabilities – Matchmaking is different Service Consumer Service Provider Security Requirements Security Requirements Security Capabilities Security Capabilities
NRL Security Ontology • Ontologies provide fine-grained semantic description and discovery • Used at all levels of SOA for security specification Password Certificate Cookie name minLength value path X.509Certificate version Organizational ontology serialNumber issuer notBefore notAfter Date/time ontology
Infrastructure level • Industry standard UDDI repositories cannot store ontology information • OWL2UDDI – Provide capabilities for ontology-based service description and discovery in UDDI using client-side modules
Web Services Level and Enterprise Application Level • Web Services Level – Describe security capabilities and requirements using NRL Security Ontology – GUI to browse ontologies, specify security, and discover services • Enterprise Application Level – Created a simple GUI that represents data flow among tasks to specify security requirements: – Capturing mission software logic that spans multiple organizations and multiple applications – Consider security requirements in the context of mission software – Bridge the gap between operational community and security community
Beyond the Paper Compose Mission Logic Goal: functional & (Business Logic) security descriptions P2 P1 P4 P3 Search Service Check status criteria selector QoS 2 Security List of 1 Service Status potential 3 Invoke the Registry services best service Web Service
Questions?
Recommend
More recommend