Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com Policies must be able to change, based on their usage over time. An example of this might be that a policy has been defined stating that e-mails to ‘Gold’ customers must always be checked by a manager, to ensure that they are polite, and follow guidelines for customer interactions. But how many times does the manager actually change the e-mail when it is checked? Can a customer service representative (or automated process) be regarded as sufficiently trusted to cut out this checking step altogether? The policy could be applied to untrusted or new people or services, but not once trust has been established. Policy is thus not always static. Some elements of policy are likely to be immutable (due to compliance requirements); others are more flexible, as illustrated by the e-mail checking example above. It will be necessary to report on policy usage and provide audit trails over time in order to provide the feedback into an iterative improvement process. The end result is that policy specification must be separable from policy implementation. SOA policy is an area that has seen a number of providers coming to market with products, and then establishing relationships with, or even being acquired by the bigger infrastructure players. When reviewing requirements for policy management and implementation, the following points should be considered: Policies should not be hard coded. Policies need to be enforced in a distributed manner. Actions and tasks should be checked against policies at run-time. Standards in this area are still developing, but again there is a likely candidate – the WS-Policy framework, which describes the rules, capabilities, and constraints of a Web service. The framework covers three A policy description can be made up of one or more policy assertions; examples include service requirements, preferences, characteristics, capabilities, and rules. specifications; WS-Policy, WS-Policy Assertions (which covers the service properties expressed by a policy description), and WS-Policy Attachments. It is a part of the WS-Security framework. A policy description can be made up of one or more policy assertions; examples include service requirements, preferences, characteristics, capabilities, and rules. Each assertion may be required or optional – for example, a preference is likely to be optional, whereas a rule will be compulsory. It is possible that a different policy should apply to a service depending on where and when that service is deployed – an example of this might be in the Financial Services sector, particularly in securities trading, where depending on where the trade request is placed, different legislation may apply to commissions and payment terms etc. When assembling services into a composite application, it is necessary to protect the whole extended ‘application’ via a policy managed solution, without altering the existing services. Policy and security therefore need to be separately managed outside the ‘application’ layer. Security issues for SOA are more complex than in older architectures. When developing any application, the issue of security is one that must be carefully considered. In an application-centric world, developers must consider security carefully, and may well need to spend a significant part of development time within each application on this. Security within a SOA world is different from the tightly coupled world in that security information needs to be shared, passed around, and understood across multiple services. A service provider does not know who or what will be accessing the service – this is the essence of decoupling. Securing the perimeter of an organisation with firewalls, Virtual Private Networks (VPNs), or security appliances will not work in a service-oriented environment that needs to set up new external relationships quickly and flexibly. Even internally, a service-oriented approach still needs security issues to be extrapolated out of the service and into the infrastructure. For this to then work across a heterogeneous architecture, standards will be vital. Secure access to business applications and to support integration between different applications is vital. There are five common security requirements – identification, authentication, authorisation, confidentiality, and integrity. On top of this there must always be an audit trail to prove conformance. 20 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA Identification Identification covers the means by which a service requester proves its origin, and this is referred to as making a claim or assertion. Such information in the Web services world is represented in the identification information stored within the service’s SOAP header. The WS-Security specification (which will be covered in more depth later) provides a standard header block, or token, which stores this information. There are a range of different tokens available. Authentication Authentication means that the user of an application or service is recognised and can prove that the service request message has, in fact, come from the sender that it claims to have. Authorisation Once an authenticated message has been received, the recipient service might need to establish what the requester is allowed to do, referred to as authorisation. Confidentiality Confidentiality, or privacy, covers the need for information being passed from one service to another to be inaccessible to unauthorised parties. This can apply to all or part of a message, and will be especially relevant if messages are likely to be transmitted outside the firewall, but even internally it may be important to ensure that personal information is kept private. Integrity The final aspect of security is integrity. This means ensuring that a message has not been modified in any way in transit. Security issues that can arise from a lack of integrity include SQL injection (where malicious code could access data that it is not authorised to) and buffer overflows. As soon as we move outside the organisation, issues of identity, authentication, and authorisation become significantly more complex because it will be necessary to share information between parties (whilst maintaining privacy and confidentiality) – and the element of trust comes in. The core requirement here is that trust needs to be built dynamically, with the security context being transported so that authentication and authorisation can be distributed and/or federated. Federated authorisation is a process by which multiple parties agree that a specified set of users can be authenticated by a given set of criteria. This approach sets up a Federated Identity Management System, or a pool of authenticated users. The SOA security solution can verify a user by checking with the Federated Identity Management System. A federated system is basically Single Sign-On (SSO) between different security domains, and currently is likely to require specialist third-party infrastructure, as support for this concept within application servers is currently limited. Validation of identity is usually covered by authorisation and access mechanisms, which can already be deployed across a wide range of architectural styles. At the entry point, most organisations moving to SOA will have at least two alternatives – Internet browser and portal-based for people, and Web services. The same set of identity information, such as SSO or federated identity attributes and access control mechanisms need to be applied in a consistent manner across both methods. It will be important to use Identity and Access Management technologies, including directories for Web services. Validation of identity is usually covered by authorisation and access mechanisms, which can already be deployed across a wide range of architectural styles. In many architectures, the way that the presentation and user interface layers are handled (including challenge and response protocols for authentication and SSO) is via a portal or portlet. A range of different user credential schemes have been deployed over the years including passwords, tokens, smart cards, and X.509 certificates. Within a Web services or SOA framework, it will be desirable to reduce the number of types of credentials used, and we are seeing Security Assertion Markup Language (SAML) and Kerberos tokens as the emerging leaders here. SAML has advantages in that its flexibility and extensibility allows support for secondary authentication credentials that might be needed to interact with legacy applications. December 2006 Section 1: SOA Deployment 21
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 19: www.butlergroup.com Planning and Im
Page 31 and 32: www.butlergroup.com Technology Mana

Planning_and_Impleme.. - didier beck weblog

Create successful ePaper yourself

Delete template?

Save as template?