DeCare Systems Ireland SOA

1. DeCare Systems IrelandSOA Eamonn Franklin Software Development Director Yagiz Erkan Chief Architect Anthony Geoghegan Framework Architect

2. Service Oriented Architecture • SOA • Definition • Background • Some Implementation Technologies • Advantages / Conclusions • Service Orientation • Principles • Remote v Co-location • Implementation Recommendations • Practical Implementation • Axioms of Security • XML Security Standards • Our Experience February , 2004 DeCare Systems Ireland 2

3. Definition(s)What is SOA? • A macro level design pattern applied at an application architectural level • A set of components which can be invoked and whose interface description can be published and discovered • A style of application architecture where autonomous services with well defined interfaces communicate via messages across heterogeneous platforms which can be discovered and are orchestrated through a loose coupling to provide a required function February , 2004 DeCare Systems Ireland 3

4. Why SOA? • Designed to achieve the vision of an Agile Enterprise • IT Cost Containment • Flexible IT Infrastructure • Regulatory Compliance • Organizational Responsiveness • Profitable Growth • How? • Based on the principal of developing reusable business services • Building applications based on these Services • Moving away from the monolithic model February , 2004 DeCare Systems Ireland 4

5. (Very)Brief History • Assembly..Iterative..Modular..OO..CBD • Challenges • Distributed Computing • Application Integration • Heterogeneous Platforms, Protocols, Devices • OMG  CORBA with IIOP • MS  DCOM, COM+ • SUN  EJB with RMI • EAI • SOAP • XML/HTTP based protocol for accessing services, objects, servers • COM & CORBA can use SOAP to communicate February , 2004 DeCare Systems Ireland 5

6. Why SOA Now? • Old challenges still exist • The Internet has made implementation practical • Availability of Standards provides Interoperability • HTTP • XML • SOAP • WSDL • UDDI • Focuses on Collaboration between Business and IT • Senior Management Understand the Benefits February , 2004 DeCare Systems Ireland 6

7. SOA Enablers • Service • Loose Coupling (Interface) • Message • Dynamic Discovery • Service Bus • Web Service February , 2004 DeCare Systems Ireland 7

8. Possible Advantages • Lower Integration Costs • Faster Delivery of Applications • Code Reuse • Platform Independence • Location Transparency • Focuses Developer • Greater Testability • More potential to Scale • Easier Extensibility February , 2004 DeCare Systems Ireland 8

9. Some Criticisms • Mostly Immature Implementations Available • Vendors Over Hyping • No Standards Body • Stateful debate continues • Web Services can be overkill • Adds complexity by default February , 2004 DeCare Systems Ireland 9

10. Conclusions • SOA is here to stay • Will offer true value if implemented correctly • Has achieved buy in • Not a panacea • Still in early stages • Cannot be truly realized without • Reference blueprints • Implementations based on best practice February , 2004 DeCare Systems Ireland 10

11. Service Orientation (SO)

12. What is a Service? • An application function put together as a reusable component for use in a business process. • A way of thinking about and organizing business functionality so it can effectively stand on its own. February , 2004 DeCare Systems Ireland 12

13. What is Service Orientation? • It is the basic requirement to have an SOA. • It is a distinct approach for analysis, design and development that introduces principles that govern aspects of communication, architecture and implementation of processing logic. February , 2004 DeCare Systems Ireland 13

14. Objects, Components & Services • Object thinking • Defined by behaviour: focus on the behaviour/responsibility • Smart data containers: state & logic. Relatively data focused. • Component thinking • Super objects: Collaborate, encapsulate others, provide higher-level interfaces • Binary reusable entities (deployment unit) February , 2004 DeCare Systems Ireland 14

15. Objects, Components & Services • Are Services • Objects on the Web? • API on the Web? • Components on the Web? • Service thinking: Services are “Message Endpoints” • No parameters • No APIs exposed • Use messages conforming predefined schemas • Platform and protocol independence February , 2004 DeCare Systems Ireland 15

16. Common Principles of SO • Loose Coupling • Formal Contract • Reusability • Abstraction • Composability • Autonomy • Statelessness • Discoverability February , 2004 DeCare Systems Ireland 16

17. Service Granularity • “How granular should a service be?” • SubmitPurchaseOrder vs. CreateNewPurchaseOrder, SetShippingAddress, AddItem, etc. • Consistency vs. flexibility • Think “business-grained” • Coarse-grained outside, fine-grained inside February , 2004 DeCare Systems Ireland 17

18. Golden Hammer Syndrome • Creating Web Services made easy using tools and frameworks. • Everything doesn’t have to be a service. • Everything doesn’t have to be remotely accessible. • Everything doesn’t have to be interoperable. • There are alternatives to XML Web Services. February , 2004 DeCare Systems Ireland 18

19. Web ServicesInteroperability Tips • WSDL and XSD first. • Use document/literal wrapped format. • Data types: • Simple array of concrete types to represent a collection of complex types. • Avoid arrays containing null elements. • Unsigned numerical types • Precision support. • Interop Testing Tool 1.1 February , 2004 DeCare Systems Ireland 19

20. Apache Axis & Spring Framework • Spring-aware Axis front controller in order to avoid using ServletEndpointSupport. • Spring-aware Axis handler chain, so that the handlers can be defined in a Spring Framework configuration file. February , 2004 DeCare Systems Ireland 20

21. Summary • Services are Message Endpoints • Adopt service-thinking • Look for business-granularity • Everything doesn’t have to be a service • Interoperability doesn’t come automatically. February , 2004 DeCare Systems Ireland 21

22. Web Service Security, let’s talk implementations! Or one way to communicate sensitive information via the Web

23. Web Services Axioms Of Security • Availability • Integrity • Confidentiality • Authentication • Authorization • Accountability February , 2004 DeCare Systems Ireland 23

24. XML Security Standards • W3C • XML Signature • XML Encryption • XML Key Management • OASIS Consortium • Web Services Security: SOAP Message Security V1.0 • Concerns encryption and signing of web services • Web Services Security: Username Token Profile V1.0 • Concerns simple username/password authentication • Web Services Security: X.509 Token Profile V1.0 • Concerns certificate based authentication February , 2004 DeCare Systems Ireland 24

25. Securing XML Messages • Apache WSS4J (Web Services Security For Java) • Sits on top of Axis and XML Sec. • Two Axis handlers provide complete functionality <deployment xmlns=“http://xml.apache.org/axis/wsdd/” xmlns:java=“http://xml.apache.org/axis/wsdd/providers/java”> <transport name="http" pivot="java:org.apache.axis.transport.http.HTTPSender"/> <globalConfiguration > <requestFlow >     <handler type="java:org.apache.ws.axis.security.WSDoAllSender" > <parameter name="action" value="Signature Encrypt"/> <parameter name="signaturePropFile" value="crypto.properties" />     </handler>    </requestFlow >   </globalConfiguration > </deployment> February , 2004 DeCare Systems Ireland 25

26. Example crypto.properties file org.apache.ws.security.crypto.merlin.keystore.password=yourpassword org.apache.ws.security.crypto.merlin.keystore.alias=long alias org.apache.ws.security.crypto.merlin.alias.password=yourpassword org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=JKS org.apache.ws.security.crypto.merlin.file=keystore.jks • Above example defines a Merlin JCE implementation. • In practise we use the bouncy castle JCE implementation. February , 2004 DeCare Systems Ireland 26

27. WS Security Threats • Message Alteration – A scheming entity can attempt to alter the contents of a message, thereby compromising the integrity of the message. • Confidentiality – Unauthorised entities can seek to gain access to confidential information within a message. • Man-in-the-middle – An attacker can seek to pose as a legitimate message intermediary in order to intercept messages transmitted between two or more parties. The parties, thinking they are communicating with each other, continue their conversation, but with messages that may be altered by the attacker or even originated or blocked by the attacker. • Identity Spoofing – Unauthorised access using authentication attacks and eavesdropping. • Content borne threats – Threats against XML payload elements. • Denial of Service (XDoS) attacks – Attacks designed to curtail provision of service. • Schema Poisoning – Manipulating the WS schema to alter the data processed by an application. • XML Parameter tampering – Injection of illegitimate scripts or content into XML Parameters. • Coercive Parsing - Injection of illegitimate content into the actual XML payload. • XML Routing Detours – Redirecting data addressed by an XML path. February , 2004 DeCare Systems Ireland 27

28. Number one lesson we at DSI have learned…

29. Preventing fat messages • Messages get fat! February , 2004 DeCare Systems Ireland 29

30. Preventing fat messages • Don’t use every type of security together • Signing for integrity, encryption for confidentiality, authentication for access control • Only use appropriate security mechanisms • Credit card data should be encrypted it does not need to be signed or even authenticated. • If somebody is emailing a decision then signing the decision makes sure the decision has not been tampered with. Encryption may be a waste of time here. • If something is not sensitive don’t protect it • A web service to tell you the time Caracas does not need to be secured. February , 2004 DeCare Systems Ireland 30

31. Conclusions: Don’t secure something unless you have to. The security should match the service.

32. DSI Authentication Solution • Using Kerberos tickets transmitted in web services message header • Use new OASIS standard for transmitting Kerberos tickets via SOAP. • Use Active Directory instance to authenticate client identity • Can also validate servers identity. February , 2004 DeCare Systems Ireland 32

33. DSI Authorisation Solution • We used the Acegi-Security framework because spring based, offering AOP support and hence method level authorisation is possible. • To this end an Active Directory security provider for the Acegi-Security framework has been developed by DSI. • Uses Kerberos and secure LDAP to authenticate and authorise message traffic. February , 2004 DeCare Systems Ireland 33

34. Kerberos For Web Services • Authentication protocol • Very secure • No password ever transmitted • All transmitted authentication data is encrypted with short lifespan keys. February , 2004 DeCare Systems Ireland 34

35. Kerberos Authentication 1 Getting the client’s credentials February , 2004 DeCare Systems Ireland 35

36. Kerberos Authentication 2 Authenticating the client and server with a Kerberos ticket February , 2004 DeCare Systems Ireland 36