Oneill SOA

8/2/2019 Oneill SOA

1/32

Mapping Security to a Services Oriented Architecture

Mark ONeill CTO, Vordel

Open Group, April 2005

8/2/2019 Oneill SOA

2/32

Open Group, April 2005 2

About the speaker

CTO of Vordel vendor of XMLsecurity products since 1999.

Author of Web Service Security,

published by Osborne/ McGraw-Hill .Contributors include Phillip Hallam-Baker (Chief Scientist at VeriSign)and Ed Simon (XMLSec In c, authorof XML Signatu re specification)

Contributing author of HardeningNetwork Security, published byOsborne/McGraw-Hil l, 2005

Published in XML Journal, WebServices Journal,PriceWaterhouseCoopersCryptographic Journal of Excellence

Background in EDI and in academiccryptography

8/2/2019 Oneill SOA

3/32

Open Group, April 2005 3

About Vordel

A vendor of XML securit y products since 1999.

Based in Dublin, London, and Boston

Customers include the European Union, theSpanish Government , Telefonica, Fortis,Experian, Ericsson, Bell Canada

Standards-based integration with identi ty-management tools

Vordel supports a wide range of open standards andspecifications and interoperates with many popularWeb Services platforms, making it a likely choice formany enterprises looking to protect their WebServices from unauthorized or malicious traffic. Jason Bloomberg - ZapThink

8/2/2019 Oneill SOA

4/32

Open Group, April 2005 4

Vordels User Conference

Speakers from Entrust , RSA Security, Softw are AG, QA Consultin g

Enterprise architects from Vordels customer base describe how theyhave integrated security into their Services Oriented Architectures

Tutorial on W eb Services Security included in confer ence fee

June 8-10 in Westbury Hotel, Dublin

8/2/2019 Oneill SOA

5/32

Open Group, April 2005 5

What I ll be speaking about

What is a Services Oriented Archit ecture?

A Whiteboard diagram How important are XML and SOAP to a SOA?

How does security map to a Services Oriented Architecture?

Transactional: Embedding security tokens in XML messages Architectural: Deploying security services XML-level: New XML-based threats

8/2/2019 Oneill SOA

6/32

Open Group, April 2005 6

First what is a Services Oriented Architecture ?

An SOA uses a Services Layer to hide underlying complexity

Businesses can save money and time b y developing agai nst thi s ServicesLayer, rather than developi ng directly against an ERP/legacy layer

Also known as a Business Interf ace Layer, or a Business Services Layer

8/2/2019 Oneill SOA

7/32

Open Group, April 2005 7

How do you go about creating a Services Oriented Architecture?

Gartner defi ne SODA as Services Oriented Development ofApplications

SODA has seven aspects:

1 . D es ig n . Focus on process-oriented design rather than component-based design. Processand workflow should be built into the design, not added later.

2 . Model l ing. Using UML or similar. Includes modelling the structure and flow of bus inessprocesses, as well as application modelling and technical modelling.

3 . Fabr i ca t ion . The actual creation of service components. Includes not only XML, but alsoadapters and integration technology

4 . Assembly. Connecting service components together. May be achieved using a visual tool.5 . Orches t ra t ion . After assembly, workflow defines how information and logic will flow

through the process. Introduces state and flow control.6 . A ut o m at i o n. Code generation to map from the model to the implementation. E.g. from

scripts, or UML, or XML to EJB or .NET components.7. Variability and rapid application maintenance. Ensures that changes to composite

systems does not break the rest of the system. Services must be able to adapt to multiplepurposes or versions.

Gartner predict t hat applicat ion development tools wil l evolve toinclude t hese seven SODA aspects.

8/2/2019 Oneill SOA

8/32

Open Group, April 2005 8

Just how important are XML and SOAP for a Services Oriented Architecture ?

XML and SOAP are certainl y a good excuse to implement a ServicesOriented Architecture now, rather t han doing i t 5 years ago.

However, the concepts of a Services Oriented Architecture go beyond the

implementation technologies used Services should be understandable by non-technical business people

Implementation technologies can be changed, without breaking the interface

Asynchronous messaging is preferable to tightly-coupled RPC styles of integration

The most important feature of XML and SOAP is that fact that they arevendor-neutral and have no competi t ion

8/2/2019 Oneill SOA

9/32

Open Group, April 2005 9

The security risks for an SOA

1 . Compl ex i t y ! Web Services are designed to reduce complexity, but if youre not careful, they can

become complex too. Unmanaged complexity breeds insecurity

2. Unauthorized access Most cross-firewall Web Services are for closed-user-groups of partners. Therefore,

access control is very important.

3. XML-level threats XML introduces new threats such as XML Denial of Service

8/2/2019 Oneill SOA

10/32

Open Group, April 2005 10

Transactional Security The architectural challenge for SOA security

Who is accessing this system? Can I m ap their id entit y to a local store?

How did t hey authenticate? When did they authenticate?

What are their enti t lements?

?

8/2/2019 Oneill SOA

11/32

Open Group, April 2005 11

Thinking in terms of t he transaction

An SOA means that users access business systems through mu ltipl e layers.

This is why it s necessary to bind the security context to XML messages .

WS-Security and SAML are important technologies for achieving this.

Then, at each layer, we have control

8/2/2019 Oneill SOA

12/32

Open Group, April 2005 12

Security tokens inside an XML message

In t his message,security tokens arehighlighted inyellow.

We see a SAMLAuthenticat ion assert ion,digital ly signed along withthe SOAP body.

[ screenshot f romVordel SOAPboxapplicat ion free

download fromwww.vordel .com ]

8/2/2019 Oneill SOA

13/32

Open Group, April 2005 13

The risk of complexity

Managing transactional security can become very complex very fast

How I do control which application can access which Web Service?

You could code/configure security policies in each Web Services platform and try to syncthem up together

Do you really want to do this?

Security policies are required here , here , here , here , and here .

( So is auditing, SLA management, reporting, etc)

8/2/2019 Oneill SOA

14/32

Open Group, April 2005 14

Security Services

So, rather than coding the same security functionality in each platform, whynot m ake use of Web Services?Authenticat ion

Username/Password AuthN (HTTP-Auth, WS-Security) Certificate Validation Token issuance (SAML)

Authorization Integration with Web Access Control SAML AuthorizationDecisionQuery

Audit Logging services

Confidentiality and Privacy Encryption Digital Rights Management

Content validation Threat scanning of XML

I n t e g r i t y OASIS Digital Signature Services (DSS), Time-stamping

8/2/2019 Oneill SOA

15/32

Open Group, April 2005 15

So how is this im plemented?

At each point w here you must consume or send XML, also apply security

Where?

At the perimeter (XML Gateway)At the Web Service endpoint (application server)

Security Services simply means deploying security functionality as WebServices that ar e on t ap as part of an SOA.

8/2/2019 Oneill SOA

16/32

Open Group, April 2005 16

The Security Bus

When a security context flows with XML messages through an SOA, throughthe use of security services, it can be thought of as a Security Bus

8/2/2019 Oneill SOA

17/32

Open Group, April 2005 17

What is the alternative to deploying reusable Security Services?

The alternat ives to deploying reu sable securit y services are:

Code and configure security rules in your Web Services platforms(.NET,J2EE, etc) and try to get them all to talk to each other

Use multiple implementations of WS-Security, SAML, etc.

Keep revisiting decisions on how to implement Web Services Security.Firstly at the XML Gateway, then at the application server, etc.

With r eusable Securit y Services, you get all of t he advantages of WebServices, for security functionality.

These Security Services can be used by an XML Gateway, and b y code atthe application server

8/2/2019 Oneill SOA

18/32

Open Group, April 2005 18

Defensive security: Blocking new XML-level thr eats

Weve looked at transactional security and at security services

Now lets look at another side of securi ty blocking content-based threats

8/2/2019 Oneill SOA

19/32

Open Group, April 2005 19

STRIDE Threat model - thinking about security in terms of threats

Developed by Michael Howard and David LeBlanc in Microsoft

Documented in Writin g Secure Code [ Microsoft Press]

The first step is to draw the data flow for a system and then identify which threat s apply at

each system entity, and at each link bet