Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

WSO2Con USA 2015: Enhancing Company-wide SSO-propagation with WSO2 ESB’s Custom Mediators

477 visualizaciones

Publicado el

At SUVA we come across various heterogeneous IT landscapes based on different vendors and technologies. Integrating all these peers brought up some challenging questions relating to security topics like company wide user-propagation (SSO). We solved these tasks with a kit of custom mediators, controlled by a set of custom sequences. Our security mediators interoperate with
SAML1.1 to SAP, SapAssertionToken from SAP to ESB
Custom-Token from/to MS Sharepoint and MS.NET
Custom-Token from/to Java Systems
BasicAuth bridge to WSSUsernameToken
BasicAuth authenticator to SAML 1.1 and custom-tokens.
This allowed us to enhance each ESB-Proxy with a highly customizable security extension by just adding three lines of code to the proxy-service definition. It is simple to enhance with additional standardized or custom security features. This session focuses on how the WSO2 ESB acts as a company wide security intermediary that liberates our systems from dealing with end-to-end security and standards they might not support.

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

WSO2Con USA 2015: Enhancing Company-wide SSO-propagation with WSO2 ESB’s Custom Mediators

  1. 1. Enhancing  companywide   SSO-­‐Propaga5on  with   WSO2  ESB  Custom  Mediators   Urs  Hürlimann   Integra5on  Architect   SUVA  
  2. 2. Business  Problem   •  How  to  consume  webservices  from  providers  with   different  security  standards?   •  Bunch  of  incompa5ble  peers.   •  Brave  new  world?   –  How  to  implement  WS-­‐Security  on  legacy  systems?   –  Each  peer  has  its  own  preferred  way  to  propagate  user   informa5on  
  3. 3. Business  Problem   •  More  than  30  different  plaMorms  in  our  company  
  4. 4. Business  Problem   Many  to  Many  Rela5onship   CRM   Legacy   Support   Services   DWH   Core   ECMS   .NET  JAVA  
  5. 5. Solu5on  Architecture   Plan  (ES)B   •  Man  in  the  middle   •  All  trust  him,  all  know  him   •  The  ESB  knows  all  the  peers   •  The  peers  don't  know  each  other  anymore   •  The  ESB  streamlines  the  communica5on  
  6. 6. Solu5on  Architecture   Divide  and  Rule   IBAN   Enterprise  Service  Bus   Bloomberg   NCBI   eInjury   Number   B2B   Partners   Intranet   Website   Business   Core   Legacy   Systems   Mail   Worklist   SAP   CRM   ECMS   Support   Services   Provider  only   Consumer   only   Bi-­‐Dirce5onal  
  7. 7. Solu5on  Architecture   A  Decoupling  Trust   SAP     Syrius  CORE  CRM     espresso  Sharepoint   ESB   asserts   ISM2   Legacy   PlaMorm   SAP    CRM  Kunde  XY  Customer   asserts   asserts   creates   BasicAuth   WS-­‐Security   SAP  Token   creates   creates   SignedToke n   SAML  SVA   SaltedToken  
  8. 8. Solu5on  Architecture   Pluggable  Interceptors   •  Incoming  Interceptors  (Asserters)   –  Six  different  kinds   •  Outgoing  Interceptors  (Bearer)   –  Eight  different  kinds   •  Highly  configurable  over  ESB  Sequences   •  Easily  expandable    
  9. 9. Solu5on  Architecture   The  Security  Sequences   <sequence  xmlns="h#p://ws.apache.org/ns/synapse"   name="ch_suva_aax_security_assert_anytoken">          <class  name="ch.suva.wso2.esb.aax_security.AssertSapSSO2TokenMediator">                  <property  name="security"  value="sufficient"/>          </class>          <class  name="ch.suva.wso2.esb.aax_security.AssertSuvaTokenMediator">                  <property  name="security"  value="sufficient"/>          </class>          <class  name="ch.suva.wso2.esb.aax_security.AssertSignedTokenMediator">                  <property  name="security"  value="sufficient"/>          </class>          <class  name="ch.suva.wso2.esb.aax_security.AssertCheckMediator"/>          <property  name="AuthorizaIon"  scope="transport"  acIon="remove"/>          <property  name="X-­‐suva-­‐token"  scope="transport"  acIon="remove"/>          <property  name="X-­‐sym-­‐token"  scope="transport"  acIon="remove"/>          <property  name="MYSAPSSO2"  scope="transport"  acIon="remove"/>   </sequence>   <sequence  xmlns="h#p://ws.apache.org/ns/synapse"   name="ch_suva_aax_security_anytoken2suvatoken">          <sequence  key="ch_suva_aax_security_assert_anytoken"/>          <class  name="ch.suva.wso2.esb.aax_security.CreateSuvaTokenMediator"/>          <property  name="X-­‐suva-­‐token"  expression="get-­‐property('SUVA_TOKEN')"   scope="transport"  type="STRING"/>   </sequence>   ESB   AXIS2  Context   Request   AXIS2  Context   Request   SYNAPSE  Context   InSequence   Security            Sequences   Custom  Bearer   Mediator   Custom  Asserter   Asserter  Custom  Asserter   Asserter   Custom  Asserter   Mediator   User  Data   Token  
  10. 10. Solu5on  Architecture   Sequences  &  Custom  Mediators   1.  Requests  arrives  on  the  ESB   2.  InSequence  calls  a  predefined  security  sequence   3.  Custom  Mediators  are  trying  to  assert  the  security  context   4.  User  informa5on  gets  stored  into  ESB's  Synapse  Context   5.  Based  on  the  security  sequence  the  propaga5on  mechanism   for  the  chosen  backend  will  be  selected   6.  Custom  Mediator  reads  user  informa5on  out  of  ESB's  Synapse   Context  and  creates  a  backend  compa5ble  token.   7.  Security  Sequence  adds  the  token  to  the  Transport  Level  
  11. 11. Solu5on  Architecture   Custom  Mediator  Sample  
  12. 12. Implementa5on  Performance   •  Write  once,  run  everywhere   –  Webservices   –  RESTful  API   •  Easy  to  use   –  Just  add  one  or  two  lines  of  code  in  the  Proxy  Service  XML   <sequence key="ch_suva_aax_security_anyauth2suvatoken"/>
  13. 13. Implementa5on  Performance   Our  Gains   •  Security  Propaga5on  always  was  a  pain   –  We  got  rid  of  it   •  We  are  flexible  for  future  requirements   –  JSON  Web  Token  will  be  next  
  14. 14. Deployment  Info   •  Deployment  unit  is  a  zip  file   –  JAR  with  ESB  Custom  Mediators   •  Target:  ../repository/components/lib   –  CAR  with  ESB  Sequences  and  Security  Policies   •  Target:  ../repository/deployment/server/carbonapps  
  15. 15. Decision  Criteria   •  The  bus  has  to  be   –  Lightweight   –  Used  and  carried  by  an  ac5ve  community   –  Developed  and  delivered  from  a  serious  vendor   •  The  vendor  has  to   –  Offer  support  which  is  more  than  a  promise   –  Offer  development  support  
  16. 16. Management   The  Seed   •  The  core  of  the  Security   Media5on  was  built  2011   within  an  one  week   WSO2  Quickstart  Program   •  All  our  consumers  and  providers  can  smoothly  join   the  ESB  empire   2010   Jan  2011   Mai  2011   Juli  2011   August  2011   September  2011   Requirements   Preliminary  Study   Evalua5on  (PoC)   Detailed  Concept   Implementa5on   Produc5ve  Use  Intranet   Building  DMZ   Produc5ve  Use  DMZ   November  2011   Februar  2012  
  17. 17. Management   The  Harvest   •  200  different  Webservice  Proxies   0 50 100 150 200 250 300 350 400 450 500 Distinct  Proxies  per  Month Webservices Operations
  18. 18. Management   The  Harvest   •  More  than  1  Million  Service  Calls  a  Day   0 5'000'000 10'000'000 15'000'000 20'000'000 25'000'000 30'000'000 35'000'000 40'000'000 45'000'000 Requests  per  Month
  19. 19. SUVA  Key  Figures  2014     •  122'617 Insured  Companies   •  1'974'000  Insured  People   •  459'921  Accidents  (96%)        Occupa5onal  Diseases  (4%) •  3'320  Employees   •  2 Company  Owned  Clinics   •  142 Billions  Insured  payroll   •  46  Billions  Investments   •  106  Millions  Opera5ng  Income  
  20. 20. Thank  You!  

×