Presentation given at the Secure360 conference in St. Paul, MN on May 12

1. Unlock the Business Potential of Service-
Oriented Architectures via Identity
Management
1
BRUCE O'DELL
SENIOR CONSULTANT, RISK MANAGEMENT
AERITAE CONSULTING GROUP LTD.
BODELL@AERITAE.COM

2. Agenda
2
 What is a service-oriented architecture (and
why should security people care)?
 Prehistoric SOAs... primitive security
 Modern SOAs... point-to-point protocols
 Internet SOAs... novel products and services
 Future SOAs... “security” disappears
 And what to watch for next

3. Defining an SOA
3
 Wikipedia
• SOA separates functions into distinct units, or
services, which developers make accessible
over a network in order to allow users to
combine and reuse them in the production of
applications.
 Key concepts
– Encapsulation, composition, discoverability,
abstraction... and, of course, re-use
– Limitless scope for SOA design pattern
• Component, application, organization,
enterprise, consortium, nation, planet...

4. But... why bother perfectly
nice security people about SOA?
4
 SOA sounds like a great idea... but
– In practice, results seldom matched the hype
– Basic security requirements (authentication,
authorization, confidentiality, non-repudiation,
integrity, denial of service...) have been key
dis-enablers of SOA
– Paradoxically security is also about to the catalyst
for an SOA renaissance
 To understand why... let's take a little trip
through SOA history

5. Platforms that time forgot
5
 Fossil records show (long ago) distributed
object protocols fought to rule the world
The OMA - Object Management Architecture - DCOM sits right in the middle of the components of your application; it
categorizes objects into four categories: the provides the invisible glue that ties things together
CORBAservices™, CORBAfacilities™,
CORBAdomain™ objects, and Application Objects.
Here is the classic OMA diagram:
Source: OMG, http://www.omg.org/gettingstarted/specintro.htm
Source: http://msdn.microsoft.com/en-us/library/ms809311.aspx
CORBA (IIOP) DCOM (DCE RPC)

6. The rise of web services
6
 Both DCOM and CORBA were for all intents
and purposes wiped out by the same
“asteroid”... the Internet
• XML over HTTP worked fine across firewalls
• Free of platform-specific security hooks
• Bridges Java, COM (and .NET) services + more
 A SOAP inventor's view
– “low-tech wire protocols based on the standards of the Internet...
I went on a private tour of execs in the industry, but none of
them (I think) had a clue what I was talking about.” - Dave
Winer

7. Web services challenges
7
 No XML security standards for a very long time
– Security interoperability = standards, but
– Multiple vendors + consensus =
 What was available …
– Transport-layer security
• Confidentiality
• Basic or cert authentication
 Proliferation of roll your own solutions

8. WS-* to the rescue?
8
 Web services security standardization
– Gradual emergence of security standards
– More gradual adoption by vendors
– Even more gradual interoperability
Key standards
 WS-Security
– How to pass credentials
 WS-Trust
– The birth of the security token

9. Unbearable coolness of
security tokens
9
 Good answer to hard questions
– Standard way to pass identity attributes
• Arbitrary assertions
• Attributes sound basis for RBAC
– Digitally signed XML
• Authentication, integrity, non-repudiation
– Self contained and verifiable
• Enables delegation of trust
• Eliminates identity management by daily
“batch file” transfer

10. Anatomy of a security token
10
<saml:Assertion
<saml:Conditions> metadata </saml:Conditions>
<saml:AuthenticationStatement
<saml:Subject>
<saml:NameIdentifier>subject</saml:NameIdentifier>
<saml:SubjectConfirmation> metadata </saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
<saml:AttributeStatement>
<saml:Subject>
<saml:NameIdentifier>name</saml:NameIdentifier>
</saml:Subject>
<saml:Attribute AttributeName="name">
<saml:AttributeValue>value</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<ds:Signature … digital signature & metadata... </ds:Signature>
</saml:Assertion>

11. Internet SOAP web
11
services?
 Vendor products began to support WS-
Security
– SAML token binding
– Digital signatures are fragile
– Cross-vendor compatibility
– Heavyweight protocol
– Token lifetime & renewal
 Web browser SOAP client?
– B2B niche, but SOAP seldom direct to end-users

12. RESTful evolution
12
 Web 2.0 – a lightweight way to browse
 REST = SOAP - except inside out
– SOAP
• complex request
• obfuscated scope
• “heavyweight” XML
security parameters
– REST
• simple request, self-evident scope
• “lightweight” query string security params

13. OpenID and OAuth
13
 Modeling identity as URI resources
 Identity providers + relying parties
– Internet single sign on
– Application to application permissioning
– User control of attribute sharing
OpenID OAuth

14. Web 2.0 threat model
14
 Deliberately break scripting “sandbox”
 JSON – render objects from content stream
 Asynchronous XML data transactions
 Cross-site request forgery
 Phishing OpenID 1.0
 Spoofing OAuth 1.0
 XML injection and DOS
 Domino effect - if federated IDP (Facebook) is
compromised, so are FacebookConnect sites

15. Federated Identity and
15
SSO
Identity Provider Site Service Provider Site
1. Authenticate 1. Receive the
the user “token”
2. Generate a 2. Verify its digital
digitally- signatures
signed “token” 3. Create a valid
3. Include one or user session on
more SP site using
attributes attributes
needed by a passed from IDP
service
provider

16. Federated account linking
16
Identity Provider Service Provider
Site A Site B
Invite user to
Recognize link site B
Identity A user is part identity
of IDP A to site A
identity
• Identity Provider Recognition: the Service Provider needs some mechanism
to recognize that a Service Provider user is also registered with an
Identity Provider within their circle of trust.
• Service Provider Enrollment: the user is invited to link their SP account to
their IDP identity, and logs in (one last time) to the SP. The linkage
is registered on the IDP end, and the SP login is bypassed in future
| Page 16

17. User-centric identity
17

18. Claims-based architecture
18
 Abstract authentication from authorization
Source: http://download.microsoft.com/download/7/D/0/7D0B5166-6A8A-418A-ADDD-95EE9B046994/Claims-Based%20Identity%20for%20Windows.pdf

19. Internet-scale SOA
19
 Combine...
– large-scale consumer IDPs
– affiliated, linked service providers
– portable consumer identity tokens
– composable, RESTful web services
– mobile, location-aware hardware
– REST-SOAP gateways to corporate services
 … for ubiquitous, SOA internet applications

20. Today, RBAC...
tomorrow, ABAC?
20
 RBAC is the best idea seldom implemented
– Role based access controls are great
– Role based access controls are awful
 Attribute based access control (ABAC)
– A subject (an attending physician)
– An action (wants to read)
– A resource (a patient's test result)
– A context (in the ER at 2:00 AM)
 Practical considerations
– Avoid RBAC complications
– Limited choice of platforms for now

21. XACML as a design pattern
21
 XACML standard for ABAC
 Abstraction of IAM complete: authentication,
authorization and policy metadata

22. XACML as a real platform
22
 More academic interest than industrial products
– Example: Axiomatics product architecture

23. Internet 3.0 web services
23
 Internet 3.0
– Web 2.0 + semantics + federated identity
 Interoperable attribute authorities
– STS-mediated circles of trust
– Semantic attribute mapping
 Multiple levels of assurance
 Ubiquitous ABAC
 Strong privacy safeguards...
– Which many will choose to ignore to gain
benefits of transparency within social networks

24. Long road to invisibility
24
 Evolution of SOA as driven by evolution of
security
– Before 1990 – monolithic platform SOAs,
monolithic security (ACF2, RACF)
– 1990 – 2000: distributed object SOAs, DCOM and
CORBA security wrappers
– 2000 – 2010: point to point SOAP with TLS
– 2010 – 2015: consumer identity federation with
portable identity
– 2015 – 2020: ABAC and semantics for compliance
and management of complexity
– 2020 – SOA ubiquitous, “security” declarative

25. Questions? YOUR
25
LOGO
 Bruce O'Dell
 Senior Consultant, Risk Management
 Aeritae Consulting Group Limited
 bodell@aeritae.com
 (651) 229-0300
 www.aeritae.com
Leaders in bringing innovation, balance, and
performance to IT organizations