Presentation is loading. Please wait.

Presentation is loading. Please wait.

Overcoming the SOA Network Fallacy

Similar presentations

Presentation on theme: "Overcoming the SOA Network Fallacy"— Presentation transcript:

1 Overcoming the SOA Network Fallacy
Roberto Medrano Executive Vice President Copyright © 2005 SOA Software, Inc. All Rights Reserved. Specifications Subject to Change Without Notice.

2 SOA Transcends the Network
If you listen to SOA advocates, you might get the idea that a Service-Oriented Architecture transcends the network: Web services consumers and providers have a logical relationship to one another – to the consumer, the Web Service is a URL, which could be anywhere, on any network segment One of the major advantages of SOA as an architectural paradigm is the concept of “network transparency” – to work, an SOA does not need any specific network configuration. The Web can be your new “corporate network” In others, when you’re thinking SOA, forget the network. The network doesn’t matter… March 28, 2017

3 The SOA Network Fallacy
Don’t get lulled into a false sense of network irrelevancy Based on the ideas of network transparency and the logical relationship between consumer and provider, some people in the EA field (sometimes SOA Vendors) conclude that the network does not matter in an SOA. This is exactly wrong. We call this the “SOA Network Fallacy” In an SOA, the network is perhaps more important than in any earlier EA paradigm: Web Services are network-based application components Consumers Providers Discovery of Web Services through the network UDDI/Registries are network-based Movement of SOAP messages, and WSDL documents over the network Security and governance for Web Services rely on network transports Movement of SAML tokens, PKI, etc. across network SOA relies on the network. Period. March 28, 2017

4 Getting into it: SOA Deployments
Customers Teleworkers Road warriors Partners Distributed Enterprise/Branch SOA Consumers Extended Enterprise Converged IP Network IP Network Campus Data Centers Private WAN or VPN SOA Apps March 28, 2017

5 General Security Characteristics of Web Services and SOA
Copyright © 2005 SOA Software, Inc. All Rights Reserved. Specifications Subject to Change Without Notice.

6 SOA security risks - Enterprise
Monolithic applications used perimeter security Componentization (separating data, business logic and presentation layers) increases the number of potential attack points The mainframe is the classic example of a monolithic app. Historically the only way to access the data or business logic in a mainframe app was to go through the green screen (3270) interface. So this was the only place where security was needed. As you service-orient these applications and expose other interfaces you now need to consider how to secure the direct access to the data and business logic layers as well as the UI. March 28, 2017

7 Security/compliance Related Characteristics of Web Services
Web services (often) use Web protocols. i.e. A Web service invocation is an RPC that goes through Port 80 Security issues Critical and/or confidential software functions may be exposed to unauthorized access Existing perimeter controls may not be effective to prevent unauthorized access Integrity/confidentiality of data exposed as Web services may be at risk Web services use XML, which is open and text-based Security issues: Eavesdropping Lack of confidentiality Malicious modification of messages in transit Accidental or malicious disclosure of sensitive information Web services are “machine to machine” i.e. The user (consumer) of Web service is another application Security Issues Access management Identity management Web services lead to new application structures and development processes Composite applications Service bus Increased and faster-paced inter-company and inter-divisional development projects SLDC and change management Governance March 28, 2017

8 More issues with Web Services and SOA security
Authentication Asserting and verifying the identity of all the parties involved Original requester Requesting application Intermediary(s) Service provider Authorization Determining if the requesting party(s) is/are authorized to access the requested resource (service/operation) Determining if the authorization is valid for this transaction (date/time, number of requests, etc.) Auditing Provide a record of who did what and when they did it Privacy Ensure that messages are safe from eavesdropping Non-repudiation Ensure that the senders cannot deny sending, and the receivers cannot deny receiving messages March 28, 2017

9 The Importance of SOA Infrastructure
Copyright © 2005 SOA Software, Inc. All Rights Reserved. Specifications Subject to Change Without Notice.

10 SOA Infrastructure SOA Infrastructure:
The complete set of tools and processes to assure security, management, mediation, and governance of Web services in an enterprise environment March 28, 2017

11 SOA Infrastructure Reference Model
SOA Infrastructure provides core infrastructure services to the SOA and XML applications and messaging layer Service providers, consumers, enterprise service bus platforms along with other service proxies, leverage these infrastructure services either directly, or via delegates and agents Infrastructure services include: Management Application Implements management standards like WS-DM to provide central performance and health monitoring and reporting capabilities Security Service Implements standards like WS-Trust and XACML as well as common PKI features Registry UDDI services for core service discovery Metadata Repository Serves policies, WSDLs, Schema, virtual service definitions and many other key meta-data items March 28, 2017

12 SOA Infrastructure Reference Model
SOA Infrastructure as an enabler of Risk Mitigation Countermeasures Intermediaries between Web service consumers and providers Centralized repository of policy meta data Dynamic definition, implementation and enforcement of policy for consumers, providers, and intermediaries Future-proofs SOA against vulnerabilities caused by changes as services evolve through the SDLC March 28, 2017

13 Secure Services Ensure the security of services
Authentication SAML Kerberos X.509 Basic Auth https Authorization Privacy (XML-Encryption) Non-repudiation (XML-Signature) Audit Ensure that consumers can comply with required security policies March 28, 2017

14 Infrastructure Security Services
Security Token Server Authentication Token Exchange e.g. HTTP cookie for SAML assertion Federation Standards WS-Trust WS-Federation Authorization Services Who can access which parts of a service XACML Delegate to existing access management solutions SiteMinder TAM Oblix, etc. PKI Services Key pair generation Certificate Management Key distribution Security services for SOA and Web services involve 3 different capability sets: Token services – authentication (i.e. who are the entities involved – original requestor, requesting application, service), token exchange (ensure interoperability between services and consumers using different technologies – a consumer that can only send http basic auth credentials, and a service that requires SAML for example), Federation (identifying valid users across identity domains – often involves token exchange – for example, a corporate user can authenticate against a local identity server at their company and get a token like a SAML assertion, they can then send this token to a partner service that can either accept the token because it recognizes the authority of the company to assert the identity of the user, or it can contact an external service that can generate an alternate token that it (the partner) understands from the original token). Authorization service – who (user or application) is allowed to do what (access an operation of a service at various times and throughput levels typically). XACML is the most commonly accepted standard in the industry for packaging Az requests and submitting them to an Az server. For example, an intermediary that speaks XACML can extract content from a message (from, to, value of PO etc) and can send this content in an XACML document to an authorization server like SIteMinder for a decision on whether or not to allow the message to reach the service. Most enterprises already have Az services like SiteMinder or TAM, so a good SOA security solution must integrate with these to allow the delegation of Az decisions. PKI services – generate key pairs, distribute keys and certs to consumer and provider applications. Essentially remove the complexity of dealing with PKI from the developers of services and consumers. March 28, 2017

15 Key Web Services security standards
WS-Security - security token enveloping SAML - authentication (and authorization) XML-Encryption (XML element privacy) XML-DigitalSignature (XML element signing) WS-Policy (asserting policies for services and operations) WS-Trust (building trust relationships and executing trust transactions) WS-Federation (formal federated identity services) These are most of the important standards in Web services security WS-Security is a general purpose enveloping standard for encapsulating security information in the SOAP envelope. It’s like the package you get attached to the outside of a FedEx box that has the manifest and signature info on it. WS-Security is used to specify what type of credential is used, and where it is; whether a message is signed, and where the signature is; which parts, if any, of the message are encrypted, and which algorithm was used; and many other security related items. It is designed to make it easy for a system that receives a message to identify and process security information. SAML is the most generally accepted XML credntial formal. It stands for Security Assertion Markup Language and is a fairly simple XML document that will be issued by a trusted authority (a Security Token Server). It asserts the identity of the bearer and is signed by the trusted authority – much like a drivers license or a passport, you carry it with you and hand it to folks saying, “this is me, the state of CA, or the US govt says so.” XML-Encryption – a way of encrypting XML and carrying the encrypted data in another XMLdocument complete with key and algorithm info. XML-DSig – the same as above, but for signature. It allows you represent a digital signature as an XML document. WS-Policy – a framework of standards that allows a service provider to specify what security policies it requres. WS-Policy is a set of standards including a wide range of “assertions” that are defined and owned by each of the standard groups that own the underlying specification, for example WS-SecurityPolicy is owned by the WS-Security working group at OASIS. The assertions are used to specify the policies pertaining to their specific area. WS-Policy also has WS-PolicyAttachement which allows you to associate WS-Policy assertions with service definitions (WSDL or UDDI entries). WS-Trust – an emerging protocol for requesting Au and Token Exchange operations, and for managing trust relationships between identity domains. WS-Federation – a framework combining other standards including SAML and WS-Trust into a complete Federation system. March 28, 2017

16 What is Security Policy?
Start with Registry Service publishing Service discovery A system of record for information about services Add a repository Store and manage metadata about the services in the registry Define and manage policies for security, management, reliability, routing, etc. Reference these policies in the service entries Repository objects can be shared by multiple registry entries (services) Change policy once affect many services Central management of policy A simple Web service client->service invocation is direct connection between a consumer and a provider with no understanding, implementation or enforcement of policy. The first step towards policy enabling (securing) this invocation is to add a provider side intermediary (Management Point) into the message path. The first thing the MP does upon receiving the message is to parse just enough of it to determine its complete destination (service and operation name). It can then look this destination up in the registry, get the location of the policy documents for this destination, and then retrieve the policy documents from the repository. Of course, a well designed intermediary like our MP maintains a cache of policy documents and service destination policies. Once the MP has the right policy for the destination it will ensure that the inbound message complies with the policy, and will perform and mediations needed (XML decryption for example) before passing the message on to its destination. The MP can either act as a proxy sitting in front of the service, or as an agent deployed in the service’s SOAP stack. The next step is essentially the reverse of the provider intermediary. In this case we can put an intermediary in the consumer call stack. This intermediary will discover policies from the registry and repository and will ensure that any messages it sends comply with the policies that will be enforced at the service. At runtime providers and consumers can leverage the policy management infrastructure Agents discover and enforce policies Delegates discover and implement policies to ensure true loose-coupling March 28, 2017

17 SOA Infrastructure Solutions
SOA Infrastructure includes Governance, Management and Security linked together through SOA Policy Management Governance offers no value without a runtime solution to enforce policies and feed back metrics and compliance data Runtime solutions (security and management) offer minimal value without central policy control and value-added service governance capabilities March 28, 2017

18 Standards-based Closed-loop SOA Infrastructure
Closed loop means: Defining and managing actionable policies in a governance solution at design-time Enforcing these policies via deep integration with a management solution at run-time Auditing that these policies are being enforced Using industry standards (WS-Policy, WS-MEX) where appropriate for information exchange Closed loop infrastructure enables demand and Value Management Collect performance, usage and exception statistics at run-time Track these statistics via the governance solution Use live, audited information to drive value-based decisions about the effectiveness of different services and organizations Provide developers with up to the minute information about a service in runtime to inform their decisions about which services to use Manage supply and demand to ensure maximum efficiency and benefit from SOA The key to this slide is the loop in the middle. A governance system defines policies which are enforced (physically actioned) by runtime security and management systems. The runtime systems collect metrics and compliance data (manifests) that they pass back to the governance system where is compares these metrics and manifest with the original policies to ensure that the policies are being correctly enforced, in an audit process. The compliance manifest is an interesting idea, essentially it is a signed document (signed by the runtime intermediary) that states exactly what the intermediary did with the message it is processing. I.e. a simple XML document stating for example – message received at, policy requirement are, verified signature, decrypted, found SAML assertion, validated assertion with SiteMinder, collected destination and value (X), authorized against SiteMinder, sent message to destination. This document would be signed by the intermediary and passed back to the governance system. This way the governance system knows that the intermediary did what it was supposed to do. This closed-loop process audits that policies are being correctly enforced. March 28, 2017

19 SOA Infrastructure – Policy Management Use Cases
Plan, analyze, design, implement, test, change, and retire design and runtime policies for services Define and manage validation and conformance policies for service design and registration Define and manage security, routing, reliability, mediation, and other runtime policies NOTE: Without deep integration with an SOA management solution, these policies will be informational only, and will not be enforced Define policies for services across all popular types of service containers including, Java and .NET app servers, ESBs, Mainframe, and packaged applications Ensure that policies are being effectively enforced with a comprehensive metric collection model Capture performance and usage metrics according to policies Statistically and algorithmically capture comprehensive message data Track and manage security and other policy exceptions Compare and reconcile collected metrics with policies for audit purposes Policies have their own lifecycle in the same way that services and any development assets do. Policy management is the process of marshalling policies through their lifecycle from planning through deprecation. Policy Management covers a wide range of policies for design and runtime including all security policies (authentication, authorization, privacy, non-repudiation, and audit). Think back to the compliance manifest discussion from earlier, a complete policy management solution needs to implement a closed-loop where it will process policy compliance manifests comparing them with the original policies to ensure compliance. March 28, 2017

20 SOA Infrastructure – Security Use Cases
Enforce policies managed by a centralized governance solution Consistent policy enforcement for all popular service containers including, Java and .NET app servers, ESBs, Mainframe, and packaged applications Enforce and mediate policies in the network Ensure the end-to-end security (Au, Az, Privacy, Audit, Non-repudiation) of Web services messages Create, manage and distribute public/private key pairs through the SOA Decouple the security model from the development process Allow developers to focus on their business logic and interfaces, allowing the infrastructure to implement and enforce security, reliability, and messaging policies Ensure the interoperability of Web services clients and service providers Policy enforcement is a question of discovering policies using the process described under “what is security policy” above, then physically implementing these policies. For example, a policy document might state that messages coming into a service must be signed, must use SAML for authnorization, and must have certain elements encrypted. The first thing the policy enforcement system (runtime intermediary) will do is to parse enough of the message to find the security header (WS-Security). It will look for an appropriate credential (SAML in this case) and if it doesn’t find it, will reject the message. If it does find a SAML assertion, it will process it and will validate that the user is authenticated. Once it has done this it will verify the signature of the message (this is a processor intensive operation, so it will only be done after authentication). If the signature is not valid the message will be rejected, if it is valid it will move on to find the encrypted data and decrypt it (if this operation fails for any reason – can’t find the encrypted data, data isn’t encrypted, encryption is invalid – then the message will be rejected). The last step in the process is to pass the message on to the service endpoint. Part of security policy enforcement is the generation, management, and distribution of cryptographic keys and their associated certificates. This is an onerous task and a complexity that should not be delegated to the developers and architects of services. Part of decoupling the complexity of the security model from the developers is the separation of the key management activities. Security interoperability is another complexity. There are currently 4 different versions of the WS-Security standard, and literally hundreds of different options for credential types and cryptographic algorithms. The security system that is used should be able to mediate between these different implementation choices to ensure interoperability. March 28, 2017

21 Policy-based SOA Infrastructure
March 28, 2017

22 SOA and Impact on the Network
Requirements around Scalability Performance Security Load balancing & failover SOA Applications SOAP XML WS* etc. March 28, 2017

23 SOA and the Network: Security
Network related risks Access control risk Endpoint integrity risks App related risks Data integrity risks SOAP Messages modified in transit Data changed or deleted by unauthorized access to databases fronted by Web Services (XML Injection) Data confidentiality risks Eavesdropping Improper access Data availability risks Denial of Service through XML exploits Endless strings, XML logic bombs March 28, 2017

24 Load balancing and failover
Unpredictable load characteristics of SOA application traffic Server side load balancing Network scalability SOA apps are 24*7 High availability of network infrastructure is a fundamental assumption How do I ensure that my SOA apps are always available? March 28, 2017

25 Scalability SOA can dramatically increase volume of network traffic (peaks and valleys) Packet sizes vary (small to large) – text based protocols How can/should you optimally engineer the network without adding substantial cost? March 28, 2017

26 Real time responsiveness & performance
SOA apps are built with LAN like performance as an assumption Composite apps – different modules from different systems working together to deliver on business process – increase performance demands of the network Delays and packet-loss can cause time-outs of SOA apps – poor end user experience Network managers need to support SLAs as SOA based apps get deployed How to manage network performance without too much cost? March 28, 2017

27 Business speed and responsiveness Busines safety Business flexibility
Checking in Do you still think the network is irrelevant to SOA? How can you develop an SOA solution approach that makes the network a strategic asset that innovates businesses and business processes How can you deliver strategic and tactical business results should not require unreasonable infrastructure trade-offs? Best Practice: implement critical network elements with an SOA Governance oriented approach Think: Business speed and responsiveness Busines safety Business flexibility March 28, 2017

28 Solving the SOA Network Challenges
You can build network reliability and security into your SOA by merging best practices of SOA Governance and infrastructure with a best of breed approach to network infrastructure. SOA and Network Infrastructure working in harmony Use SOA Infrastructure management tools to estimate SOA load and harmonize/optimize consumer and provider connections on the network Understand where mediation is necessary between incompatible links in the network that supports your SOA ESB mediation Transport protocol transformation Routing paths Provide for version control, failover, load balancing as an SOA management issue, and integrate with underlying network infrastructure – you need both to succeed Selecting the right SOA infrastructure and network solutions Understand where you need an XML firewall Work with network solution provider to optimize network performance characteristics for SOA Work with network solution provider to resolve potential security issues at the network level Embedding Network aspects of the SOA into SOA Governance Web Service governance policy metadata can include network parameters Centralized SOA governance can provide SOA network management capabilities Work toward a “closed loop” of SOA Governance that enforces governance policies that are defined at design time – in that way, there is reduced risk of lapses in governance policy enforcement for Web services that are live on the network at runtime March 28, 2017

Download ppt "Overcoming the SOA Network Fallacy"

Similar presentations

Ads by Google