Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com Ideally, security should not even be part of many of the infrastructure elements, such as the ESB; it should be a capability that can be used as required by whatever infrastructure pieces are in use. Solving SOA security issues is likely to require the implementation of specialist security tools or infrastructure – examples come from SOA Software, Layer 7, and Amberpoint, as well as the main SOA infrastructure players. An interesting extension to this argument comes from the networking layer, with Cisco starting to provide some elements of security. During the summer of 2006, Cisco announced its Service Oriented Network Architecture (SONA) strategy. Currently, this is a mixture of its AON product combined with services, which sees the network as rather more than a transport layer – it is becoming a platform. SONA allows specific services to be provided as part of the network, such as identity, VPN services, and presence services from mobility, so that they can then be used within applications and composite applications. Standards for SOA security and policy are starting to mature, and interoperability is improving. As with many standards, the issue in the SOA arena is the sheer volume of them, which many organisations find confusing, and tends to muddy the water around SOA rather than provide clarity. A glance at Figure 8.4.1 will give an indication of the scale here. One of the key positive elements is the formation of the Web Services Interoperability Organisation, WS-I.org, which is working to at least ensure that different models, products, and platforms can work together. Web Services – * XML Identity WS-Security WS-SecurityPolicy WS-Trust WS-Secure Conversation WS-Federation WS-Federation Active Requester Profile WS-Federation Passive Requester Profile WS-Policy WS-PolicyAssertions WS-PolicyAttachment eXtensible Access Control Markup Language (XACML) XML Key Management (XKMS) eXtensible Rights Markup Language (XrML) XML-Signature XML-Encryption .NET Passport Liberty Alliance Security Assertion Markup Language (SAML) Figure 8.4.1: SOA Security Specifications The WS-I is made up of a number of software vendors, both from technology and applications backgrounds, including BEA Systems, Fujitsu, HP, IBM, Intel, Microsoft, Oracle, SAP, Sun, and webMethods. Its objective is to promote interoperability across platforms, operating systems, and programming languages. The WS-I is not a standards body as such, but incorporates standards from a number of bodies such as the IETF, OASIS, and W3C. 22 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA The most important consideration currently is the existence of the Web Services Interoperability Basic Profile. This defines a mechanism for interoperability for the core standards used in Web services implementations, and covers SOAP, WSDL, and UDDI as well as some lower-level standards and protocols. The Basic Profile version 1.0 is not fully compatible with version 1.1 – guidance here is that usage of the standard should be at the same level to ensure interoperability. The Web services security (WS-Security) specification that has been developed and ratified by OASIS provides security for SOAP messages in transit, and can be regarded as an extension to SOAP. Originally developed by IBM, Microsoft, and Verisign, where messages need to pass across an untrusted intermediary structure, standards such as WS-Security provide a degree of trust, covering authenticity, integrity, and confidentiality of messages. Security can be applied at transport level (for example Secure Sockets Layer (SSL) secures the HTTP layer on which various requests and responses are transmitted). However, where a message is sent via an intermediary, the transport layer no longer has control over the message when it is at the intermediary, and therefore it may also be necessary to implement message-level security – like keeping a message within a sealed, tamper-evident envelope. The WS-Security standard is already reasonably mature – version 1.0 was approved by OASIS in April 2004, and version 1.1 was approved in February 2006. The WS-Security family specifications cover the use of various different tokens, such as Kerberos, X.509, and SAML. An example of a signed security token is an X.509 certificate; this asserts a binding between the requester’s identity and a public key. Security tokens like this can be carried in a message, or expressed by a reference so that the receiving service can ‘pull’ the claim from the relevant authority. To ensure interoperability, adapters and common algorithms for signatures and encryption will need to be agreed upon. The WS-Security model is extensible, and allows a service to specify the type and degree of security required. The WS-Interoperability Basic Profile includes Security. Web services gateways, message brokers, and ESBs may provide the trust required themselves, and services that interrelate only within an ESB may not need to consider security. However, if they are to be exposed beyond this, then security will be needed. RUN-TIME OPTIONS FOR SOA CATALYST When most people think of SOA they automatically assume that Web services will be the way that services interact, and have concerns about the efficiency of such deployments. However, a SOA can have a number of deployment alternatives which can help get around some, but not all, of the performance issues. SUMMARY There is a trade-off possible between performance and long-term agility, and this needs consideration before committing to a course of action. Network appliance alternatives to traditional server/software implementation can offer cost/performance benefits. Run-time deployment of SOA-based applications does not always mean using Web services. High-performance SOA need not be an oxymoron, but good understanding of issues is needed. December 2006 Section 1: SOA Deployment 23
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 21: www.butlergroup.com Planning and Im
Page 31 and 32: www.butlergroup.com Technology Mana

Planning_and_Impleme.. - didier beck weblog

Create successful ePaper yourself

Delete template?

Save as template?