Your SlideShare is downloading. ×
Konzepte einer Sicherheitsarchitektur für eine SOA am Beispiel der eFA SOA Security - So What? BITKOM Workshop SOA&Securit...
Contents <ul><li>Setting the Scene </li></ul><ul><li>Architectural Recipe </li></ul><ul><li>Solution Blueprint </li></ul><...
Setting the Scene The IT-Security Issue Before SOA <ul><li>A “law of nature” in IT: </li></ul>Application Application clie...
Setting the Scene How Does SOA Change the Picture? <ul><li>Dynamics: </li></ul><ul><ul><li>Require opening-up user populat...
Architectural Recipe  Externalize Security as a Cross-Cutting Concern Service Consumer IDs/creds  and PoP Ids, creds Authz...
Architectural Recipe  Decouple Authorization from Initial Authentication  Service Authz subsystem Consumes Service Authn s...
Solution Blueprint  Authentication Subsystem - What to Consider? Service Consumer <ul><li>Work-split: </li></ul><ul><ul><l...
Solution Blueprint  Authentication Subsystem - How to Employ? <ul><li>In practice, this basic pattern is iterated e.g.: </...
Solution Blueprint  Authorization Subsystem - What to Consider? Service <ul><li>Work-split: </li></ul><ul><ul><li>PEP: nee...
Solution Blueprint  Authorization Subsystem – Which Expressiveness? HTTP header SOAP header SOAP body WS application WS-st...
Solution Blueprint  Authorization Subsystem - How to Employ? HTTP header SOAP header SOAP body WS application WS-stack e.g...
WS-Stack Integration <ul><li>WS-based SOA systems typically build upon off-the-shelf WS-stacks e.g. Apache Axis, Microsoft...
Spotting eFA on the Radar-Screen eFA IdentityProvider STS: WS-Trust STS with specific WSDL and SAML assertion profile eFA ...
About the Siemens Realization for eFA Security <ul><li>Functional properties: </li></ul><ul><ul><li>Java 1.6-based realiza...
Conclusions <ul><li>Security is a cross-cutting concern in SOA. It requires to adapt new concepts and technologies includi...
Abbreviations <ul><li>AOP Aspect Oriented Programming </li></ul><ul><li>DAC Discretionary Access Control </li></ul><ul><li...
Author <ul><li>Dr. Oliver Pfaff Siemens AG Med GS SEC DI 1 E-Mail: oliver.pfaff@siemens.com </li></ul>
Backup
WS-Stack Integration J2SE  Subject  (supplying authn subject information from the stack). JAX-WS  SOAPMessageContext  prop...
Technology Innovation <ul><li>Technology innovation helps to realize the architectural recipe: </li></ul><ul><ul><li>SAML:...
Upcoming SlideShare
Loading in...5
×

SOA Security - So What?

906

Published on

This presentation examines architectural patterns for SOA security according the externalization of the cross-cutting concerns of authorization and authentication as well as the integration of identity federation. Conceptual building blocks for SOA security are sketched and assessed with respect to classical security means. Web services-based SOA systems are considered in particular. The analysis considers the native security functionality of common Web service stacks (e.g. Apache Axis, Microsoft WCF, Sun JAX-WS RI/WSIT).

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
906
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "SOA Security - So What?"

  1. 1. Konzepte einer Sicherheitsarchitektur für eine SOA am Beispiel der eFA SOA Security - So What? BITKOM Workshop SOA&Security, Franfurt/Main 2008-03-12
  2. 2. Contents <ul><li>Setting the Scene </li></ul><ul><li>Architectural Recipe </li></ul><ul><li>Solution Blueprint </li></ul><ul><li>WS-Stack Integration </li></ul><ul><li>Spotting eFA on the Radar-Screen / About the Siemens Realization for eFA Security </li></ul><ul><li>Conclusions </li></ul>
  3. 3. Setting the Scene The IT-Security Issue Before SOA <ul><li>A “law of nature” in IT: </li></ul>Application Application client <ul><li>This applies to every IT-system like gravity applies to any spot on Earth. It especially holds for: </li></ul><ul><ul><li>Health care e.g. eFA </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><ul><li>SOA </li></ul></ul>Authorization <ul><ul><li>Serving valuable resources in an automated fashion mandates authorization </li></ul></ul>Authentication <ul><li>Authorization calls for authentication </li></ul>Identifiers, credentials <ul><ul><li>Authentication depends on identifiers, credentials </li></ul></ul>
  4. 4. Setting the Scene How Does SOA Change the Picture? <ul><li>Dynamics: </li></ul><ul><ul><li>Require opening-up user populations that can be served (identity federation) and related authorization models (e.g. attribute-based authorization). </li></ul></ul><ul><li>Loose coupling: </li></ul><ul><ul><li>Traditional security architectures with their rigid coupling between authorization (consumer of authenticated subject information) and authentication (producer of such information) are incompatible with SOA. </li></ul></ul><ul><li>Heterogeneity: </li></ul><ul><ul><li>Security aspects are being modeled as part of the service contract. This is based on a declarative modeling of cryptographic protocols and required security tokens. </li></ul></ul><ul><li>Innovation: </li></ul><ul><ul><li>WS-based SOA need to adapt XML security technologies e.g. WS-Security, WS-Trust, SAML, XACML. </li></ul></ul><ul><li>Further influences: Web 2.0 concepts such as user-centric identity (CardSpace, OpenID) and self-determination (also relevant in health care: my body->my data->my control). </li></ul>
  5. 5. Architectural Recipe Externalize Security as a Cross-Cutting Concern Service Consumer IDs/creds and PoP Ids, creds Authz Authn Consumer Service Naïve approach: DIY <ul><li>Coupling between supply and use of security </li></ul><ul><li>Duplication of work </li></ul><ul><li>… </li></ul>Ids, creds Authz Authn … … IDs/creds and PoP Service Consumer Ids, creds Authz Authn Consumer Service Ids, creds Authz Authn … … IDs/creds and PoP IDs/creds and PoP Service Consumer Ids, creds Authz Authn Consumer Service Ids, creds Authz Authn … … Advanced approach: re-use Authz Ids, creds Authn Service Consumer Service Consumer IDs/creds and PoP
  6. 6. Architectural Recipe Decouple Authorization from Initial Authentication Service Authz subsystem Consumes Service Authn subject: id=John Doe cakePref=Streusel authnMethod=SSL Authz subsystem Initial authn endpoint Initial authn protocol: Cert=MI… PoP=SSLSign(SrvNonce) Consumes Authn subject: Produces id=John Doe cakePref=Streusel authnMethod=SSL Traditional approach: piggybacked <ul><li>Causes identity enclaves </li></ul><ul><li>Mandates RPs to be IdPs </li></ul><ul><li>… </li></ul>User account: id=John Doe altSubjectId=MI… cakePref=Streusel … Initial authn endpoint Initial authn protocol User account: id=John Doe altSubjectId=MI… cakePref=Streusel … Initial authn endpoint Initial authn protocol: Cert=MI… PoP=SSLSign(SrvNonce) Produces User account: id=John Doe altSubjectId=MI… cakePref=Streusel … Federated approach: split work Federated authn protocol: Assertion=<id=John Doe, prefCake=Streusel> PoP=WSSESign(SrvNonce) Fed. authn endpoint Produces prefCake::= cakePref Attr mapping:
  7. 7. Solution Blueprint Authentication Subsystem - What to Consider? Service Consumer <ul><li>Work-split: </li></ul><ul><ul><li>Issuer: (typically) external </li></ul></ul><ul><ul><li>Claimant: service consumer </li></ul></ul><ul><ul><li>Verifier: needs to reside in the service application or its call stack </li></ul></ul><ul><li>Considered authentication subsystem artifacts: </li></ul><ul><ul><li>Issuer: issues reference information (e.g. identifiers, credentials) </li></ul></ul><ul><ul><li>Claimant: claims identity and needs to prove it </li></ul></ul><ul><ul><li>Verifier: verifies identity claims and their proofs </li></ul></ul>Claimant Verifier Issuer IDs/creds and PoP
  8. 8. Solution Blueprint Authentication Subsystem - How to Employ? <ul><li>In practice, this basic pattern is iterated e.g.: </li></ul><ul><ul><li>Tertiary authn: via SAML assertions (prerequisite for service access) </li></ul></ul><ul><ul><li>Secondary authn: via X.509 certificates (prerequisite for SAML assertion issuance) </li></ul></ul><ul><ul><li>Primary authn: via ID-cards (prerequisite for X.509 certificate issuance) </li></ul></ul>Claimant Verifier Service Consumer Issuer Authz <ul><li>Architectural trick: </li></ul><ul><ul><li>Treat internal user populations with the same approach by e.g. introducing a password-based authentication service issuing SAML assertions. </li></ul></ul><ul><ul><li>Simplifies verifiers by requiring them to support either initial authn (with local user accounts) or federated authentication. </li></ul></ul>SAML service SAML assertion and PoP SAML assertion Verifier X.509 certificate and PoP X.509 service Issuer Verifier ID-card and PoP X.509 certificate
  9. 9. Solution Blueprint Authorization Subsystem - What to Consider? Service <ul><li>Work-split: </li></ul><ul><ul><li>PEP: needs to reside in the service application or its call stack </li></ul></ul><ul><ul><li>PDP: can be externalized from the service application and its call stack (via local or remote communications) </li></ul></ul><ul><ul><li>PMA: can be externalized from the service application and its call stack </li></ul></ul><ul><li>Considered authorization subsystem artifacts: </li></ul><ul><ul><li>PEP: Policy Enforcement Point </li></ul></ul><ul><ul><li>PDP: Policy Decision Point </li></ul></ul><ul><ul><li>PMA: Policy Management Authority </li></ul></ul>PEP PDP PMA Authz decision request Authz decision response Authz policy PEP Service PDP Authz decision (piggybacked with request) PMA Authz policy Authorization decision push: Authorization decision pull: PEP Service PDP PMA Authz decision request Authz decision response Authz policy (piggybacked with request) Authorization policy push: <ul><li>These options apply to various models: </li></ul><ul><ul><li>Authorization decision pull </li></ul></ul><ul><ul><li>Authorization decision push </li></ul></ul><ul><ul><li>Authorization policy push </li></ul></ul>
  10. 10. Solution Blueprint Authorization Subsystem – Which Expressiveness? HTTP header SOAP header SOAP body WS application WS-stack e.g. JAX-WS RI/ WSIT HTTP stack e.g. Tomcat servlet container <ul><li>Subject-related abstractions: </li></ul><ul><ul><li>Authentication subsystem-specific </li></ul></ul><ul><ul><li>May comprise information managed in external domains. </li></ul></ul><ul><ul><li>In eFA: HL7 II elements with organization and role affiliations of a subject </li></ul></ul><ul><li>Resource-related abstractions: </li></ul><ul><ul><li>Application-specific resource identifiers and attributes. </li></ul></ul><ul><ul><li>WS addressing information </li></ul></ul><ul><ul><li>In eFA: HL7 II elements specifying information objects </li></ul></ul><ul><li>Action-related abstractions: </li></ul><ul><ul><li>Application-specific action identifiers and attributes </li></ul></ul><ul><ul><li>WS operation information </li></ul></ul><ul><ul><li>In eFA: names of eFA WS primitives </li></ul></ul><ul><li>This makes the case for attribute-based authorization: </li></ul><ul><ul><li>Subject identifiers and attributes managed in external domains need to be handled to cover identity federation </li></ul></ul><ul><ul><li>An application-specific vocabulary needs to be handled to deliver application-aware authorization </li></ul></ul>
  11. 11. Solution Blueprint Authorization Subsystem - How to Employ? HTTP header SOAP header SOAP body WS application WS-stack e.g. JAX-WS RI/ WSIT HTTP-stack e.g. Tomcat servlet container PEP <ul><li>PEPs residing in HTTP-stacks: </li></ul><ul><ul><li>Decoupled from application sources or binaries </li></ul></ul><ul><ul><li>Limited to coarse-grained request authorization (may subject X access the service application?) </li></ul></ul><ul><ul><li>Limited to HTTP authentication protocols </li></ul></ul><ul><ul><li>Hard to hand-over properties to application </li></ul></ul>PEP <ul><li>PEPs residing in WS-stacks: </li></ul><ul><ul><li>Decoupled from application sources or binaries </li></ul></ul><ul><ul><li>Allows fine-grained request authorization as far as authorization-relevant information is available in request </li></ul></ul><ul><ul><li>Supports WS authentication protocols </li></ul></ul><ul><ul><li>Relies on WS-stack to hand-over properties to application </li></ul></ul>PEP <ul><li>PEPs residing in WS applications: </li></ul><ul><ul><li>In case of AOP, no impact on application sources; need to integrate API calls otherwise </li></ul></ul><ul><ul><li>Allows arbitrarily fine-grained request authorization (may subject X call method Y upon resource Z?) </li></ul></ul><ul><ul><li>Needs to consume authentication state from WS-stack </li></ul></ul>
  12. 12. WS-Stack Integration <ul><li>WS-based SOA systems typically build upon off-the-shelf WS-stacks e.g. Apache Axis, Microsoft WCF, Sun JAX-WS RI/WSIT. </li></ul><ul><li>Authorization properties of these WS-stacks: </li></ul><ul><ul><li>All support externalization through an extensible SOAP handler-chain pipeline. This allows to employ an authorization subsystem via PEPs. </li></ul></ul><ul><ul><li>Microsoft WCF provides native support for claim-centric authorization. If this does not meet given authorization requirements, externalization can be realized on several levels (PEP, PDP and/or PMA). </li></ul></ul><ul><li>Authentication properties of these WS-stacks: </li></ul><ul><ul><li>All support the processing of WSSE-defined identifiers and credentials as well as their PoP. </li></ul></ul><ul><ul><li>All allow augmenting an authenticated subject identity in an application-specific way through an extensible SOAP handler-chain pipeline. </li></ul></ul><ul><ul><li>All allow propagating authenticated identity towards service applications. </li></ul></ul>
  13. 13. Spotting eFA on the Radar-Screen eFA IdentityProvider STS: WS-Trust STS with specific WSDL and SAML assertion profile eFA ECRAdmissionTokenService: eFA-specific business logic eFA ECRAccessTokenService: nucleus for an authorization policy push support in WS environments eFA &quot;PEPs&quot;: somewhat eFA-specific since they need to understand eFA application service primitives (to some degree) and the eFA SAML assertion vocabulary Potential of re-use Distinguishes between: - Health pro-determined operations: eFA IdentityProvider STS - Health pro and patient-determined operations: eFA ECRAdmissionTokenService - Health pro, patient and ECR-determined operations: eFA ECRAccessTokenService Note: handling of multiple SAML assertions (in one ECR/MDO request context) is an implication of this separation Separation of functional concerns eFA IdentityProvider STS: encapsulates the processing of X.509 certificates and access to persisted user data eFA ECRAdmissionTokenService: encapsulates the pseudonymization of a patient and health professional context eFA ECRAccessTokenService: encapsulates the look-up of authorization policies Work split between architectural artifacts Relies on SAML, SOAP Message Security, WS-SecurityPolicy, WS-Trust, XACML Does not yet use WSFED Adaptation to technology innovation Relies on an n-ary authentication architecture where: - eFA application services: consume SAML assertions plus PoP - eFA security services: issue SAML assertions and consume X.509 certificates plus PoP - Ext. security services: issue X.509 certificates and consume whatever is appropriate given their CPS Note that this simplifies things somewhat as eFA security is based on multiple SAML assertions (cf. below) and adds authentication architecture artifacts issuing SAML assertions while consuming (other) SAML assertions plus PoP Authentication architecture Relies on a DAC authorization model addressing patient consent (my body->my data->my control) Modeled according authorization policy push PEPs may reside in WS-stacks or the service applications (e.g. through AOP) Requires a fine-grained SOAP request parsing to lookup identifiers and match them Authorization architecture Allows to isolate endpoints for verifying initial authentication based on X.509 certificates Requires application services to &quot;only&quot; process SAML assertions issued by eFA Decoupling authorization from initial authentication Separates medical application architecture from security architecture Externalizing security as a cross-cutting concern eFA specification Aspect
  14. 14. About the Siemens Realization for eFA Security <ul><li>Functional properties: </li></ul><ul><ul><li>Java 1.6-based realization of the eFA security subsystem </li></ul></ul><ul><ul><li>JAX-WS RI/WSIT is being used for SOAP header processing </li></ul></ul><ul><ul><li>Actual request processing done in own code (incl. own WS-Trust STSs) </li></ul></ul><ul><ul><li>eFA IdentityProvider STS, ECRAdmissionTokenService, ECRAccessTokenService offload processing tasks to a security server </li></ul></ul><ul><ul><li>eFA “PEPs” reside as implementations of the JAX-WS SOAPHandler interface in the WS-stack. They use the JAX-WS SOAPMessageContext to transfer security-related information to the actual applications. </li></ul></ul><ul><li>Non-functional properties (here: approx. added security overhead): </li></ul><ul><ul><li>eFA identity / admission / access assertion acquisition: 0,18 / 0,11 / 0,15 s </li></ul></ul><ul><ul><li>eFA application service operation: 0,10 s </li></ul></ul><ul><li>Lessons learned: </li></ul><ul><ul><li>The eFA specification stresses the security features of currently available WS-stacks: </li></ul></ul><ul><ul><ul><li>About 145 forum interactions between the Siemens development team for eFA security and the WSIT team at Sun over 6 months. About 10 bugs were reported. </li></ul></ul></ul><ul><ul><ul><li>We did not get the impression that other projects worldwide were burdening the properties of this WS-stack to the same degree as we had to do. </li></ul></ul></ul>
  15. 15. Conclusions <ul><li>Security is a cross-cutting concern in SOA. It requires to adapt new concepts and technologies including: </li></ul><ul><ul><li>Identity federation </li></ul></ul><ul><ul><li>Attribute-based authorization </li></ul></ul><ul><ul><li>XML security technologies for WS-based SOA </li></ul></ul><ul><li>Do SOA security the SOA way: </li></ul><ul><ul><li>Work-split: separate supply of security functionality from its usage </li></ul></ul><ul><ul><li>Self-containment: encapsulate security functionality in form of services </li></ul></ul><ul><ul><li>Re-use: use these security services in business application </li></ul></ul><ul><ul><li>Loose-coupling: decouple authorization from initial authentication </li></ul></ul><ul><li>The features of WS-stacks contribute to SOA security but do not solve the overall security problem. </li></ul>
  16. 16. Abbreviations <ul><li>AOP Aspect Oriented Programming </li></ul><ul><li>DAC Discretionary Access Control </li></ul><ul><li>eFA Elektronische Fallakte (engl.: ECR – Electronic Case Record) </li></ul><ul><li>IdP Identity Provider </li></ul><ul><li>JAX-WS Java API for XML-based Web Services </li></ul><ul><li>PDP Policy Decision Point </li></ul><ul><li>PEP Policy Enforcement Point </li></ul><ul><li>PoP Proof-of-Possession </li></ul><ul><li>PMA Policy Management Authority </li></ul><ul><li>RP Resource Provider </li></ul><ul><li>SAML Security Assertion Markup Language </li></ul><ul><li>SOA Service-Oriented Architecture </li></ul><ul><li>SSO Single Sign On </li></ul><ul><li>STS Security Token Service </li></ul><ul><li>WCF Windows Communication Foundation </li></ul><ul><li>WS Web Services </li></ul><ul><li>WSDL Web Services Description Language </li></ul><ul><li>WSFED Web Services Federation </li></ul><ul><li>WSIT Web Services Interoperability Technologies </li></ul><ul><li>WSSE Web Services Security Extensions </li></ul><ul><li>XACML eXtensible Access Markup Language </li></ul>
  17. 17. Author <ul><li>Dr. Oliver Pfaff Siemens AG Med GS SEC DI 1 E-Mail: oliver.pfaff@siemens.com </li></ul>
  18. 18. Backup
  19. 19. WS-Stack Integration J2SE Subject (supplying authn subject information from the stack). JAX-WS SOAPMessageContext properties (by agreement between SOAP handler and WS application) .NET IPrincipal (supplying authn subject information from the stack) .NET Context properties (by agreement between SOAP handler and WS application) J2SE Principal , X509Certificate and OpenSAML SAMLAssertion (supplying authn subject information from the stack). Axis2 MessageContext properties (by agreement between SOAP handler and WS application) Propagating authenticated identity (WS stack->service, custom SOAP handler->service)   Via SOAP handler-chain plugin Via WCF interceptor Via SOAP handler-chain plugin User account / attr mapping integration   Verification of WSSE-supported credentials; callback-based means to match against reference information (e.g. passwords) Verification of WSSE-supported credentials; custom validators allow to match against reference information (e.g. passwords) Verification of WSSE-supported credentials; callback-based means to match against reference information (e.g. passwords) Verifier   Processing of WSSE-supported credentials; callback-based means to lookup credentials (e.g. from keystores) Processing of WSSE-supported credentials; callback-based means to lookup credentials (e.g. from keystores) Processing of WSSE-supported credentials; callback-based means to lookup credentials (e.g. from keystores) Claimant   External, has base class for a WS-Trust STS External External, has base class for a WS-Trust STS Issuer         Authentication Not constrained Not constrained resp. native constraints (claim-centric) Not constrained Model   External External, has native PMA (can be interfaced via IAuthorizationPolicy ) External PMA   External External, has native PDP ( ServiceAuthorizationManager ) and supports extensions of it External PDP   As SOAP handler-chain plugin (implementing interface JAX-WS SOAPHandler ) As WCF interceptor (implementing interface IDispatchMessageInspector ); also has native PEP As SOAP handler-chain plugin (extending Axis2 class AbstractHandler ) PEP         Authorization Sun JAX-WS RI/WSIT Microsoft WCF Apache Axis2 Aspects
  20. 20. Technology Innovation <ul><li>Technology innovation helps to realize the architectural recipe: </li></ul><ul><ul><li>SAML: expressing information about authenticated subjects and defining identity federation protocols for traditional Web applications (accessed though so-called passive clients aka Web browsers); supporting federated authentication </li></ul></ul><ul><ul><li>SOAP Message Security: defining cryptographic protection upon SOAP messages; supporting SOAP message authentication and confidentiality </li></ul></ul><ul><ul><li>WS-SecurityPolicy: expressing security policies; supporting security-related negotiations between services and their consumers </li></ul></ul><ul><ul><li>WS-Trust: defining a framework for processing security tokens (issuance, renewal, cancellation, validation, negotiation); supporting security token acquisition </li></ul></ul><ul><ul><li>WSFED: defining identity federation protocols for WS (accessed though so-called active clients aka WS clients); supporting federated authentication </li></ul></ul><ul><ul><li>XACML: expressing authorization policies (for rendering authorization decisions) and authorization decision requests / responses; supporting arbitrary authorization models including ABAC </li></ul></ul><ul><li>Note that there are no competing traditional security technologies for these innovations. </li></ul>Representing authn users Protecting messages Negotiating security Acquiring sec. tokens Federated authn (WS) Authz base technology

×