0 mclean, va august 8, 2006 soa, semantics and security
TRANSCRIPT
1
McLean, VAAugust 8, 2006
SOA, Semantics and Security
2
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 Provider’s 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
High Level DescriptionHigh 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 Provider’s 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 Provider’s 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
... 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
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
TraditionalFirewall
TraditionalFirewall
XMLFirewall
XMLFirewall
SecurityPEP
SecurityPEP
Identity & Attribute Store AuthorizationPolicy Store
PKI
PolicyDecisionService
AttributeInformation
Service
PolicyInformation
Service
CertificateValidationService
AuditService
Service Logs
Identity & Attribute Store AuthorizationPolicy Store
PKI
PolicyDecisionService
AttributeInformation
Service
PolicyInformation
Service
CertificateValidationService
AuditService
Service Logs
Components illustrated are solely logical … capabilities may be combined based on COTS capabilities
6
Some of the places that taxonomies and semantics matter
Legend:
“In-Line Authorization” “Pre-Authorization”
PEP – Policy Enforcement Point AP – Attribute Point PDP – Policy Decision Point
What policy should I apply to
a service request?
What attributes canI forward to a PEP?
How should I expressthe action I’d like
to execute?
What do the attributes mean?