1. 0 McLean, VA August 8, 2006 SOA, Semantics and Security

2. 1 SOA interactions require answering five key questions 1.How can the Consumer dynamically discover the existence of a Provider, which can provide the services being requested? 2.Assuming the Consumer knows of the Providers existence, how can it locate the Provider? 3.Assuming the Consumer has located the Provider, how can the two describe how to connect to each other, in a standard format which can be understood regardless of their IT platforms? 4.Assuming they have described themselves, how can they exchange messages in a common messaging format which is independent of their underlying platforms? 5.Assuming they have agreed upon a common messaging format, what data format can they use to exchange data independent of their underlying database technologies? Application 1 Service Consumer Application 2 Service Provider

3. 2 High Level Description Web Service Provider (Provider) develops its description and specifies its interfaces using WSDL, and registers itself in the public UDDI registry Web Service Consumer (Consumer) queries the UDDI registry in real time, and discovers that Provider has services it is looking for Consumer downloads Providers WSDL specification from the Provider (including the format of SOAP messages the Provider can accept) Consumer then develops a request in the form of an XML based SOAP message (using a SOAP engine to translate from its native format to SOAP) Consumer then calls Provider by sending the SOAP message over HTTP Provider receives the SOAP message and translates to its own native format using a SOAP decoder Provider composes a reply as a SOAP message in a format which can be understood by Consumer (the incoming SOAP message from Consumer also includes information on the format of SOAP messages it can accept) Provider then replies to Consumer by sending the SOAP message over HTTP Web Service Provider (Provider) develops its description and specifies its interfaces using WSDL, and registers itself in the public UDDI registry Web Service Consumer (Consumer) queries the UDDI registry in real time, and discovers that Provider has services it is looking for Consumer downloads Providers WSDL specification from the Provider (including the format of SOAP messages the Provider can accept) Consumer then develops a request in the form of an XML based SOAP message (using a SOAP engine to translate from its native format to SOAP) Consumer then calls Provider by sending the SOAP message over HTTP Provider receives the SOAP message and translates to its own native format using a SOAP decoder Provider composes a reply as a SOAP message in a format which can be understood by Consumer (the incoming SOAP message from Consumer also includes information on the format of SOAP messages it can accept) Provider then replies to Consumer by sending the SOAP message over HTTP Reference models, architecture, specifications and standards realize SOA interactions only in part; semantics are also vital 1 2 3 5 8 1 2 3 4 5 6 7 8 Application 1 Service Consumer Application 2 Service Provider UDDI Service Registry 4 6 7 Semantics are most often thought of in terms of understanding messages and functions...

4. 3... semantics are necessary to properly secure services also! Sharing information sharing across organizational boundaries requires semantics not only to properly interact with services but also to properly secure services also. Shared semantics help to: –Locate and trust sources of information used to understand or enforce security requirements –Comprehend the available data upon which policy authors can to craft access control policy –Distribute decision and enforcement of access control policies –Represent service identity and authentication information to services Even the various authorization models that can be applied to an SOA require shared understanding of attributes, policy and authoritative sources –Attribute based access control –Attribute taxonomies –Service taxonomies

5. 4 Semantics and security are key pieces of successful interactions across organizational boundaries Complete SOA Security solution augments traditional security solutions and infrastructure to provide a more robust application layer security model Lines of communication utilize Transport Layer Security (SSL) Messages signed to provide message level security (message integrity) –Protects message integrity when handled by intermediaries Organization A Service Provider Organization B Service Consumer Traditional Firewall Traditional Firewall XML Firewall XML Firewall Security PEP Security PEP Identity & Attribute StoreAuthorization Policy Store PKI Policy Decision Service Attribute Information Service Policy Information Service Certificate Validation Service Audit Service Service Logs Identity & Attribute StoreAuthorization Policy Store PKI Policy Decision Service Attribute Information Service Policy Information Service Certificate Validation Service Audit Service Service Logs Components illustrated are solely logical … capabilities may be combined based on COTS capabilities

6. 5 Some of the places that taxonomies and semantics matter Legend: In-Line AuthorizationPre-Authorization PEP – Policy Enforcement Point AP – Attribute Point PDP – Policy Decision Point What policy should I apply to a service request? What attributes can I forward to a PEP? How should I express the action Id like to execute? What do the attributes mean?

7. 6 Questions? Rebekah Metz Booz Allen Hamilton Telephone: 703.377.1471 Email: metz_rebekah@bah.com