> But before doing any of that, they should be doing threat analysis to
> determine just what kind of security they need and where which will then
> drive what they decide to do.
Before attempting to do a threat analysis of an individual service or application, the security program office must provide guidance on how to do threat assessments, and what mitigation strategies should be applied based on the results of a threat assessment. The security program office should also provide frameworks that make it as easy as possible for developers to then implement those mitigration strategies. The framework in turn use the comprehensive security infrastructure to secure the systems in compliance with the policies defined.
A security infrastructure should rely on layered defenses -- a combination of perimeter layer and identity and access layer policy enforcement points (PEP). The perimeter layer (DMZ, firewalls, proxy servers, VPNs, etc) provides identity-independent protection, typically based on location, form, or content. The identity and access layer PEPs control access based on identity, transaction state, or application content.
Many organizations deploy an XML gateway in the DMZ as a centralized identity and access layer PEP. I also recommend using XML gateways as an intermediary PEP for internal communications. As Anil says, it's useful to offload expensive processing functions to these appliances, like validation, transformation, encryption, and signature processing. They are also very useful for doing credential mapping, enabling relatively easy cross-domain integration. I recommend using a SOA management system ( e.g., Actional or AmberPoint) to implement endpoint-based PEPs. These PEPs should be responsible for auditing and authorization.
Note that both types of products support any type of XML messaging (POX, RSS, SOAP, ebXML, etc). If you are using SOAP, they fully support WS-Security.
Anne
On 5/30/06, Anil John <[EMAIL PROTECTED]> wrote:
>I mean, I think I disagree that XML gateways move "most of
>the effort" out of the business logic per se, neither does it become
>"relatively simple". XML gateways do "in transit" kinds of things,
>i.e. they can translate, route, wrap, and unwrap. That can be
>difficult in itself. There is still a need for security, identity,
>roles, etc. in the business logic per se that requires a good bit of
>effort.
Implementation of a solid SOA Security Infrastructure is dependent on many
things that Enterprises have put into place before SOA came along, such as
Identity Management and PKI Infrastructure.
The attraction that a XML Security Gateway holds for me is two fold:
1) It is a "Gateway" to my services; As such it is a single point of policy
enforcement (Of course, it is incumbent on me as I build out my
infrastructure, to make sure that it is not a single point of failure by
load balancing/clustering them)
2) While I could do certain things such as digital signature checking, xml
schema validation etc. using my Java/.NET service platform, off-loading
those types of tasks to a hardware device such as an XML Security Gateway
provides me with a significant increase in performance.
Regards,
- Anil
------------------------ Yahoo! Groups Sponsor --------------------~-->
Everything you need is oneclick away. Make Yahoo! your home pagenow.
http://us.click.yahoo.com/AHchtC/4FxNAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
