Securing SOA:Meeting the Challenge

Kevin T. SmithTechnical Director, ManTech International

About the Presenter • Architect of SOA Security

solutions for many government customers

• Killer of Trees - Books and Articles focusing on SW Engineering, Web Services, XML, Enterprise Architecture, and SOA Security

Recent Book: Applied SOA (Published this Month!)

• Speaker – SOA Security Workshop Presenter at many conferences (RSA, JavaOne, ApacheCon, Net-Centric Warfare, AFEI, Semtech, OMG, Potomac Forum, etc. )

Contributing Author

Why Some Get OverwhelmedFederated Identity

Key Management

Multi-Level Security

Politics involved with “standards bodies”, vendors, partial implementations…

PBACSingle Sign-On

Authentication

Authorization Integrity

Confidentiality

Auditing

RBAC

Non-Repudiation

Availability

ABAC PADBAC

WS-Security Kerberos Token Profile

PKI

XKMS

Liberty AllianceSAMLXACML XML Signature

WS-Security

XML Encryption

Kerberos

SSL

IPSec

TLS

WS-Policy

WS-Trust

WS-Availability

WS-SecureConversation

Passport

WS-SecurityPolicy

WS-Security SAML Token Profile

WS-Security Kerberos Token Profile

WS-Security X.509 Certificate Profile

WS-Security REL Token Profile

Agenda

• 4 SOA Security Challenges• 2 Good Practices • A Few “Gotchas” to Avoid: Avoiding

SOA Security Pitfalls • Final Thoughts

4 SOA Security Challenges

Challenge 1: A Change in Mindset Required

We can no longer only think Point-to Point Security,We need End-To-End Security Solutions!

Client Service

Service

Service

Service

Service

Service

Client Service

Not just …. But Also

Challenge 2: A Dynamic Environment

• From a security standpoint, “expect the unexpected!”– Assume that services

will be used in a way that you did not anticipate!!

• The interface & consequence of every service call must be explicitly defined and understood!

• Run-time Management & Governance required

B C D

E F G

H I J

A

Chances are, B-J don’t know that they are all participatingin the same message request

Challenge 3: User Distance

• Authentication & Authorization:– Each node may need to know who the

end-user is and what they can do• Single Sign-On:

– If nodes B-J have different login credentials for the user, we don’t want to force the user to log in 9 times!

• Confidentiality– Not all nodes in the middle may be

allowed to see all data in the transaction• Integrity

– Need to have assurance that message has not been altered in transit

• Performance – Every network call and all cryptography

will lead to performance degradation

B C D

E F G

H I J

A

Challenge 3, Continued -(Transitive Trust – Avoiding the “Kevin Bacon” Game)

• Transitive Trust Solutions– “Kevin told Bob to tell Fred to tell me

that I can take $500 out of his account. So I am here to make a withdrawal please.”

– Certain standards allow trust propagation and transitive trust options

• SAML• WS-Security SAML Token Profile• Certain Gov’t SOA Standards..

• Many man-in-the middle attacks– If token is not signed, must trust B-J not

to alter the token between points– If token is signed, must trust B-J to use

token in the way that does not violate its conditions of use

• Many options, based on which Access Control Policy Model you use

B C D

E F G

H I J

Label

ALabel

A

Label

A

Label

ALabel

A

Label

A

Label

ALabel

A

Am I really sure that this is Kevin

Bacon?

PKICertificate

Challenge 4: Access Ctrl Policy Enforcement• Centralized Management, Centralized

Decision Making– “Does Kevin have permission to

access me?” (Yes/No Policy Model)• Decentralized Management, Delegated

Decision Making – Local services express & enforce their

own policy based on user credentials• Centralized Management, Delegated

Decision Making– Policy “pushed”/syndicated to, or

retrieved by local service • Pre-Determined Authorization Decision

Based Access Control (PADBAC)– Requests include Signed

Authorization Decisions • Each has performance/security

implications

APolicy

ServiceBDoes Kevin have

permission?

A AttributeServiceB

What are Kevin’sAttributes so

I can make a decisionBased on locally

Expressed policy?

A Batts

Instant DecisionBased on LocallyExpressed Policy

DecisionBased on Call to Policy Service

A

Policy“Push”Service

B

Sends policyupdates

Instant DecisionBased on Globally Expressed Policy

A BAuthorization

decision Instant EnforcementBased on PreviouslyAgreed Upon Decision

atts

Two Good Practices for Meeting the Challenges

Use of Accepted Standards• Utilize accepted standards for Messaging Security (WS-

Security * Token Profiles) • Explore the Use of WS-Trust STS for establishing trust &

conveying of subject tokens• Each standard has multiple options, some containing

risks and potential vulnerabilities that should be studied -not all options are correct for your enterprise.

• Applied SOA contains an overview of many of the accepted standards, along with decision flowcharts which may help you determine: – approaches to use for identity/attribute propagation – access control enforcement methodologies

Use of Interceptors for Achieving Security Goals

The Interoperability Is In The Messaging. Embrace multiple options for policy enforcement.

Avoiding Some “Gotchas”:A Few Security Pitfalls

Pitfall #1 – Security Planning Anti-Patterns

• “Shock and Paralysis”

• “Security at the Last Minute”

• “Death By Security”

See "Avoiding SOA Security Anti-Patterns: Practical Planning for Success", SOAInstitute.org, May 2008.

Pitfall #2 – The “Kevin Bacon” Game• Make sure that your

governance team identifies:– Conditions of use of

tokens– When and when not to

use “sender-vouches”• Explore authentication

delegation & token creation to a trusted entity, separating trust of sender & asserter

B C D

E F G

H I J

Label

ALabel

A

Label

A

Label

ALabel

A

Label

A

Label

ALabel

A

Am I really sure that this is Kevin

Bacon?

PKICertificate

Service(S)

A(S) C

(S)B(S)

D(S)

Portal

Secret User

TS OOPS!(S)

Pitfall #3 - Forgetting to Secure Your Data • Some focus so much on

access control to services, that they forget to control access to the data

• On government projects, especially, data must be marked with access control (releasability) markings & filtered on the way back to the user

• Header-level vs. Element-level solutions

Pitfall #4 – Security Related Tight Coupling

Service

A C E

B D

Will changes in your service’sconnection policy require

client integration?

• A good practice is to separate security logic & business logic between– Security handlers or

related components– The logic of the service

themselves • But what about the clients of

your services adhering to your connection policy? – If you change your

messaging security, do your clients have to re-write client handlers, etc?

– If so, you are tightly-coupled to your clients.

Confidentiality

Integrity Authentication&

Authorization

Performance&

Availability

Pitfall #5 – No Security Scalability Planning

Understand the double-edged sword of cryptography and network calls to security services.

Final Thoughts• Good SOA Security Solutions are doable if you…

– Plan from the beginning (requirements analysis, security architecture & governance)

– Use well-accepted standards– Hire SOA Security professionals – Plan for performance and scalability

• Detailed SOA Security Blueprints & Best Practices are available in the “SOA Security” chapter of Applied SOA: Service Oriented Architecture and Design Strategies.