[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE] [IMAGE] Web Services (continued) [IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]
[IMAGE]
[IMAGE] [IMAGE] [IMAGE] [IMAGE]

• Bake security into development. Security must function as a design partner not solely as an auditor. Involve security early and often in the SOA software development lifecycle. Since developers have historically viewed security as an impediment, be proactive, presenting cost- and time-savers such as reusable security services.
  
  For example, browser-based single sign-on using SAML enables better, faster, cheaper authentication services that can span multiple application boundaries.
  
  Offer expertise through threat-modeling services to help define the security requirements for the project, and provide security and QA testing.



• Look beyond the center. IT security must embrace decentralized security architectures, as SOA pushes data and decision-making out to the edges of organizations.
  
  The architectural problem is how to enforce security policy consistently on distributed endpoints and intermediaries you probably don't control and/or can't continually audit.
  
  These may include adding semi-autonomous remote branch offices, agents working from home, and outsourced development and business processes. Security architecture for services such as authentication, authorization and auditing must embrace this new order.



• Get the message. SOA is an XML message document-oriented way of organizing systems. In traditional IT security, the server authenticates and authorizes the client based on the request. However, under SOA integration, the message document contains the information the service provider--not a single central server--requires to perform authentication and authorization.
  
  The security architecture must reflect this; it's the single biggest mind-set shift for many IT security organizations.
  
  This model requires IT security to be agile in collaborating with business goals, because it relies less on hard physical boundaries and auditing every intermediary endpoint.
  
  The messages are protected with encryption, digital signatures and content validation whether or not they are in use in Amsterdam, Sydney or Rome.

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   6  |   7  |   8  |   9  |   10  |   11  |   NEXT PAGE  >