« Edging Towards Secure Application Development | Main | Penetration Testing Like a True Hacker »

Someone attending next Wednesday's SOA Security Roundtable asked the following question:

There are a lot of levels in security that need to get "stitched in" to provide process level security in the SOA enterprise. A quick review of the more obvious ones:

1. Identity verification ... authenticating the user is who they claim to be (password, digital signature, ...)
2. Role assignment ... defining a set of corporate "roles" across the whole enterprise, and provisioning users to them.
3. Access enforcement ... via SAML assertions(?) around key service point access to ensure only authorized users with the correct ID can invoke selected functionality.
4. Monitoring / reporting all access to sensitive (ex: customer) data ... a BAM function.
5. A set of business process definitions (BPELs) which correctly link the authentication and BAM services into the existing processes flow to meet predefined security constraints in SOA service governance policies.
and so on.

Question: How does an architect step back and compose "SOA Security" out of these discrete components, supplied by a variety of software vendors? Are there SOA best practices, SOA security design patterns, precanned BPEL or ... ??

Answer: There is no easy answer to that question without going into an entire treatise on SOA Security. But this topic, and many others, will be covered extensively at next Wednesday's SOA security roundtable. Sign up right here.

Posted by pschooff in |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/3172