• Save
Identity 2.0, Web services and SOA in Health Care
Upcoming SlideShare
Loading in...5
×
 

Identity 2.0, Web services and SOA in Health Care

on

  • 1,062 views

Buzzwords such as Identity 2.0, Web services and SOA characterize the architectures of novel IT-systems. Concerning these recent trends, the stake holders of eHealth systems might ask a number of ...

Buzzwords such as Identity 2.0, Web services and SOA characterize the architectures of novel IT-systems. Concerning these recent trends, the stake holders of eHealth systems might ask a number of questions including:
• Users: does that help us in providing a better care?
• Owners: how does it change the suite of applications and services we provide?
• Suppliers: what is the footprint on our software architecture?
This presentation will discuss the relevance of Identity 2.0, Web services and SOA for IT-systems in health-care. It will identify and assess the value that can be added through ideas and technologies behind these trends. Regarding the fundamental concept of identity, architectural blueprints for Web services and SOA-based eHealth systems will also be investigated.

Statistics

Views

Total Views
1,062
Views on SlideShare
1,061
Embed Views
1

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Identity 2.0, Web services and SOA in Health Care Identity 2.0, Web services and SOA in Health Care Presentation Transcript

    • European Identity Conference 2008, Munich 2008-04-22/25 Identity 2.0, Web Services and SOA in Health-Care
    • Contents
      • Setting the Scene
      • Benchmark Scenario
      • Buzzword Scouting
      • Identity 2.0
      • Conclusions
    • Setting the Scene IT-Landscape in eHealth – A Vendor’s Perspective System layer System layer System layer System layer Integration layer Integration layer Integration layer Integration layer HIS ERP … Presentation Health professionals Health care provider 1 System layer Integration layer System layer Integration layer System layer Integration layer System layer Integration layer HIS ERP … Presentation Health professionals Health care provider 2 Cooperate
    • Setting the Scene Medical Cases Often Involve Multiple Providers
      • In a majority of medical cases, patients are treated by health professionals at different providers e.g. for John Doe’s leg fracture:
        • Emergency medical services by Red Cross
        • Emergency room in hospital A
        • Surgery in hospital A
        • General care in rehabilitation center B
      • Inter-organizational care teams are being formed in an ad-hoc fashion for the treatment of medical cases
      • Medical data objects (short: MDOs) e.g. X-ray images, diagnosis documents, referral letters… belonging to a medical case are being created at the involved health care providers
      • This typical scenario is not yet well-supported in eHealth. Care teams still need to work like they used to do some 30 years ago (telephone, document exchange through couriers, fax…)
    • Benchmark Scenario The Electronic Case Records Scenario
          • Challenge 1: definition and processing of metadata (beyond MDOs)
          • Challenge 2: integrate external IT- services; federated authentication and authorization
      Health care provider 1 MDO 1,1 MDO 1,2 MDO 1,n … Health care provider 2 MDO 2,1 MDO 2,2 MDO 2,n … Health care provider 3 MDO 3,1 MDO 3,2 MDO 3,n … Case: John Doe’s leg fracture ECR
      • Electronic Case Records (short: ECRs) integrate MDOs:
        • According to medical cases
        • Across health care providers
      • Do not redefine or reinvent MDOs; add value beyond MDOs
      • Provide physicians with a tool to cooperate with other health professionals
      • Contents of MDOs and ECRs are a responsibility of the care team
      • Based on patient consent ( my body  my data  my control )
    • Benchmark Scenario The ECR Security Challenge From 10.000 Feet
      • There are following provider roles:
      Column Resource provider Has: services providing resources
        • Resource providers:
          • Do service resources (MDOs/ECRs) belonging to their organizations
          • Aim at providing access for (internal or external) members of a care team
      Has: unauthenticated user data Column Identity provider
        • Identity providers:
          • Do maintain user accounts for health professionals belonging to their organizations
          • Aim at enabling them to access (internal and external) resources of cases where they are care team members
      Row Transient data Row Persisted data Clockwise or counter- clockwise?
      • Key question: how to bring application services and user data together?
        • Clockwise
        • Counter-clockwise
      Has: unauthenticated user data
    • Buzzword Scouting Identity 2.0 Has: persisted, unauthenticated user data Has: service providing resources Column Identity provider Column Resource provider Row Transient data Row Persisted data doTransfer doAuthn
      • Identity 2.0 pattern - clockwise:
        • First authenticate against persisted local data (any traditional scheme)
        • Then transfer authenticated subject identity as secured, marshaled information over the network (e.g. SAML assertions)
      doTransfer doAuthn
      • Identity 1.0 pattern – counter-clockwise:
        • First transfer unauthenticated user data over the network (e.g. SPML, DSML, LDIF)
        • Then authenticate against persisted local data (any traditional scheme)
    • Buzzword Scouting Why Identity 2.0 Is Natural But (Still) Strange?
      • Society is built upon a decoupling between means of production and use of product , trivially stated: it is not mandatory to own a cow if you want to drink milk
      • Due to IT-security legacy, this natural decoupling appears to be the exception while the exception appears natural in IT:
        • The Identity 1.0 pattern is commonplace in distributed IT-systems:
          • It lacks separation between means of production (identity data) and use of product (consuming authentication for authorization purposes)
          • This translates to the suggestion that owning a cow (= meansOfProduction) is a prerequisite for drinking milk (= useOfProduct)
        • The Identity 2.0 pattern still is an exception:
          • It relies on separation between means of production and use of product
          • This translates to the suggestion that it is not mandatory to own a cow (= meansOfProduction) if you want to drink milk (= useOfProduct)
    • Buzzword Scouting Web Services and SOA
      • Web services (WS for short):
        • A new breed of Web applications that are entirely based on XML and that publish service contracts
        • Motivation: make the Web consumable for IT-processes
      • SOA:
        • A new paradigm for architecting software (self-contained, business functionality that is loosely-coupled)
        • Motivation: improve re-use of software
      SOA Web services School-of-thought for organizing software Means to integrate external IT-services via Web Web services- based SOA
      • WS-based SOA is a sweet spot:
        • Inside-out: SOA-based systems are easy to WS-enable in an evolutionary fashion
        • Outside-in: SOA provides a natural organization principle for code that implements WS interfaces
    • Identity 2.0 Becomes Default in WS-Based SOA
      • SAML assertions provide a standard format to securely marshal authenticated subject information for WSs and traditional Web applications:
        • WSs support holder-of-key subject confirmation models
        • Web applications are limited to bearer models
      • WSs have a native understanding about their handling (Web applications do not):
        • Request SAML assertions: through WS-SecurityPolicy sections in WSDLs
        • Issue SAML assertions: through WS-Trust STS WSs ( sp:IssuedToken ) or arbitrary WSs ( sp:SamlToken )
        • Transfer SAML assertions: as child elements of wsse:Security SOAP headers
      • (Almost) all is off-the-shelf:
        • WS-stacks natively support request, transfer and parsing of SAML assertions
        • Issuance requires WS-Trust STSs or STS-style WSs; the supply and consumption of SAML assertion contents (usually) is solution-specific
      • Web services are federation-enabled from birth; no magic beyond the standard functionality is needed for their federation resp. Identity 2.0 enablement.
        • Attention - a false friend: WSFED is no prerequisite for identity federation in WSs
    • Identity 2.0 Support in WS-Based SOA Application logic WS stack processBusinessObject <dependsOnAuthn> WS consumer requestSecurityToken <reportsOnAuthn> WS provider Application logic WS stack Resources <RP> <IdP> Identity store STS provider STS logic WS stack <wsp:Policy …> <sp:ProtectionToken> … <sp:IssuedToken…> <sp:RequestSecurityTokenTemplate> <wst:TokenType> urn:oasis:names:tc:SAML:2.0:assertion </wst:TokenType> <wst:KeyType>…</wst:KeyType> <wst:KeySize>256</wst:KeySize> </sp:RequestSecurityTokenTemplate>… </sp:IssuedToken> </sp:ProtectionToken> </wsp:Policy> SAML assertion RAM representation
    • Identity 2.0 Underlying Architectural Proposition
      • As WS provider, say what you need and let the WS consumer take care
      • Motivation:
        • Separation of concerns: RPs shall focus on processing actual business resources; IdPs on processing actual identity data
        • Dependency injection: decouple the use of information from lookup and maintaining
        • Efficiency: offload processing tasks from RPs
        • Statelessness: remove state assumptions from RPs
        • Re-use: the retrieved information might be re-usable for the WS consumer
      • Go beyond the basics:
        • Can be used with identity-centric information but is not limited to it
          • E.g. authorization policy information encompassing information about resources
        • Can be used with persisted information but is not limited to it
          • E.g. dynamically created values such as pseudonyms
        • Can be used iteratively:
          • E.g. a WS may ask for input from multiple STSs or STS-style WSs
        • Can be used recursively:
          • E.g. an STS WS may ask for further input from other STSs or STS-style STSs
    • Identity 2.0 Addressing the ECR Challenge – eFA Business WSs client logic WS stack WS consumers RReg WS RReg logic WS stack Interceptors (PEP/PDP) processing IdT / AdT / AcT / PoT Folder/MDO relation, MDO metadata DReg WS DReg logic WS stack eFA security WSs (cf. below) FReg WS FReg logic WS stack In: IdT / AdT In: IdT / AcT / PoT In: IdT / AcT / PoT In: IdT / AcT / PoT ECR/folder relation, folder metadata Patient/ECR relation, ECR metadata DRep WS DRep logic WS stack MDOs
    • Identity 2.0 Addressing the ECR Challenge – eFA Security WSs Client logic WS stack WS consumers Identity store IdT STS IdT logic WS stack AdT WS AdT logic WS stack AcT WS AcT logic WS stack Policy store (DAC) Key store PoT WS PoT logic WS stack eFA business WSs (cf. above) Stub Full content GuT STS GuT logic WS stack In: IdT / AcT Out: PoT In: IdT / AdT Out: AcT In: IdT Out: AdT In: GuT (ext user) or X509Token (int user) Out: IdT In: arbitrary Out: GuT Arbitrary
    • Conclusions
      • Regarding eHealth trends and perspectives, following initiatives are outstanding:
        • SOA: innovates the way how software is being organized
        • Web services: allow to integrate external IT-services via Web
        • Identity 2.0: provides a fundamental pattern for addressing security as a cross-cutting concern in eHealth
      • It makes sense to see these initiatives in conjunction:
        • SOA & Web services: make an integration of external IT-services evolutionary
        • Web services & Identity 2.0: make things straightforward – no extra magic needed
      • Covering the considered ECR scenario:
        • The eFA (www.fallakte.de) resolution of ECR scenario mainly builds upon Web services as a means to define the ECR services and to integrate external services via Web plus Identity 2.0 as a fundamental pattern for the security architecture:
          • Customers: various German hospitals
          • Specification: Fraunhofer ISST
          • Realization: various eHealth vendors incl. Siemens Med (Soarian Integrated Care)
      • For other eHealth scenarios:
        • Identity 2.0, Web services and SOA are perceived as fundamental building blocks for next-generation eHealth systems
    • Abbreviations
      • AcT (eFA) AccessToken
      • AdT (eFA) AdmissionToken
      • ECR Electronic Case Record
      • eFA elektronische Fallakte (engl.: ECR)
      • FReg (eFA) Folder Registry
      • IdT (eFA) IdentityToken
      • DReg (eFA) Document Registry
      • DRep (eFA) Document Repository
      • DAC Discretionary Access Control
      • GuT (eFA) GuarantorToken
      • IdP Identity Provider
      • MDO Medical Data Object
      • PoT (eFA) PolicyToken
      • SOA Service-Oriented Architecture
      • RAM Random Access Memory
      • RP Resource Provider
      • RReg (eFA) Record Registry
      • STS Security Token Service
      • WS Web Services
      • WSDL Web Services Description Language
      • WSFED WS-Federation
    • Author
      • Dr. Oliver Pfaff Siemens AG Med GS SEC DI 1 E-Mail: oliver.pfaff@siemens.com