Unlock the Business Potential of Service-
   Oriented Architectures via Identity
             Management
                 ...
Agenda
                          2

 What is a service-oriented architecture (and
    why should security people care)?
...
Defining an SOA
                          3
 Wikipedia
     • SOA separates functions into distinct units, or
       serv...
But... why bother perfectly
                 nice security people about SOA?
                           4

 SOA sounds li...
Platforms that time forgot
                                                                  5

  Fossil records show (lo...
The rise of web services
                                 6

 Both DCOM and CORBA were for all intents
 and purposes wipe...
Web services challenges
                          7

 No XML security standards for a very long time
  – Security interop...
WS-* to the rescue?
                          8

 Web services security standardization
  – Gradual emergence of security...
Unbearable coolness of
                      security tokens
                          9

 Good answer to hard questions
...
Anatomy of a security token
                                10
<saml:Assertion
 <saml:Conditions> metadata </saml:Conditio...
Internet SOAP web
                           11
                              services?
 Vendor products began to support...
RESTful evolution
                         12

 Web 2.0 – a lightweight way to browse
 REST = SOAP - except inside out
 ...
OpenID and OAuth
                         13

 Modeling identity as URI resources
 Identity providers + relying parties
...
Web 2.0 threat model
                        14

 Deliberately break scripting “sandbox”
 JSON – render objects from con...
Federated Identity and
                              15
                                 SSO
Identity Provider Site       ...
Federated account linking
                                         16

             Identity Provider                     ...
User-centric identity
    17
Claims-based architecture
                                                                   18

 Abstract authentication...
Internet-scale SOA
                        19

 Combine...
  –   large-scale consumer IDPs
  –   affiliated, linked servi...
Today, RBAC...
                       tomorrow, ABAC?
                            20

 RBAC is the best idea seldom imple...
XACML as a design pattern
                       21

 XACML standard for ABAC




 Abstraction of IAM complete: authenti...
XACML as a real platform
                        22

 More academic interest than industrial products
  – Example: Axioma...
Internet 3.0 web services
                         23

 Internet 3.0
  – Web 2.0 + semantics + federated identity
 Inter...
Long road to invisibility
                         24
 Evolution of SOA as driven by evolution of
 security
  – Before 19...
Questions?          YOUR
                       25
                                     LOGO

 Bruce O'Dell
 Senior Cons...
Upcoming SlideShare
Loading in …5
×

O Dell Secure360 Presentation5 12 10b

819 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
819
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

O Dell Secure360 Presentation5 12 10b

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17. User-centric identity 17
  18. 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. 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. 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. 21. XACML as a design pattern 21  XACML standard for ABAC  Abstraction of IAM complete: authentication, authorization and policy metadata
  22. 22. XACML as a real platform 22  More academic interest than industrial products – Example: Axiomatics product architecture
  23. 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. 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. 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

×