1. 1 Policy-Enabling the SCA-based SOA www.oasis-open.org

2. 2 Why should SCA-based SOAs be policy-controlled with SCA Policy? How does it make my SOA more secure? How does it make my SOA more agile for changing business needs? What are the basics about SCA Policy? How is policy represented? What SCA constructs can be policy-controlled? How is a particular policy attached to a particular SCA construct? What are the basic policy intents pre-defined within SCA Policy? How does policy-control affect component wiring or references to services? How do I start using SCA Policy? What are the decisions I need to make? What is an outline of the suggested steps? What policy language do I use? What SCA implementation do I use? What are some ideas for future research? www.oasis-open.org Questions to answer

3. 3 Why use SCA Policy in my SOA? You are using SCA (if you're not...)‏ Today's SOAs need to be... Deployable in different environments Ensure security Adaptable to changing business needs SCA Policy is the SCA piece that addresses those concerns

4. 4 How does it enable better security? Intents capture abstract policy requirements Intents independent of policy language and implementation The framework enables choosing a concrete policy set that satifies those intents Policy enables faster reconfiguration to meet new threats

5. 5 How does it increase SOA agility? Interactions only enabled if under policy Means we can control our interactions with our intent rather than a program Example: Requiring intent 'confidentiality.message.body' means the only SCA bindings used will be ones that can encrypt the body of the messages Can reconfigure for completely new environments, just by changing policy and re- assembling

6. 6 Covering the basic questions What are the basics about SCA Policy? How is policy represented? What SCA constructs can be policy-controlled? How is a particular policy attached to a particular SCA construct? What are the basic policy intents pre-defined within SCA Policy? How does policy-control affect component wiring or references to services? What are the decisions you need to make?

7. 7 As XML, in definitions.xml Policy types: interaction vs implementation Abstract vs concrete: Intents & Policy Sets Policy language: In theory: you choose In sanity: use WS-Policy ++ (more on this later)‏ How is policy represented?

8. 8 Intent Example - From the SCA Policy Overview webinar <intent name="sca:messageProtection" constrains="sca:binding" requires="sca:confidentiality sca:integrity"> Protect messages from unauthorized reading or modification.

9. 9 Policy set example (using WS-Policy) ‏ <policySet name="sca:userNameTokenHashPassword" provides="sca:authentication" appliesTo="sca:binding.ws"> - From the SCA Policy Overview webinar

10. 10 A 2 nd policy example (not WS-Policy) ‏ <policySet provides="sns:logging.trace" appliesTo="sca:implementation.bpel">

11. 11 What constructs can be controlled? Both intents and policy sets can be applied to any SCA construct used in the definition of components and composites Both can be applied at development If only intents specified then the matching policy sets will be determined at deployment If policy sets and intents then the applicable policy can be overridden by policy matched by intents at deployment

12. 12 How is policy attached to a construct? @requires A requires attribute specifies a space separated list of intents Complex intents can be specified using an Xpath expression @policySets The policy set applicable is specified by a policySet attribute, also a space separated list

13. 13 What are the pre-defined intents? SCA Policy pre-defines three types of policy intents: security, reliability, and misc. There are three security intents Authentication Confidentiality Integrity The reliability intents are AtLeastOnce AtMostOnce ExactlyOnce Ordered The misc. intents: SOAP JMS NoListener BP.1_1.

14. 14 The security intents Authentication Ensures stated sender is actual sender Confidentiality Ensures only receiver can read msg Integrity Ensures msg is as sent, no tampering Two qualifiers can be applied to any of these: transport and message

15. 15 Reliability Intents AtMostOnce Multiple copies of message not allowe Delivery not guaranteed AtLeastOnce Multiple copies allowed Delivery guaranteed ExactlyOnce Profile intent that combines the above Ordered Each sender's messages are delivered in order sent

16. 16 Misc. intents SOAP SOAP msg APIs used Not necessarily ws binding, could be SOAP over JMS for example, but ws binding likely JMS JMS msg APIs used, JMS binding likely NoListener Client can't accept new connections Only on references Ex: a WS-Policy assertion that applies to the binding, which requires the use of WS-Addressing with anonymous responses (e.g. required ” BP.1_1 WS-BasicProfile is followed, ws binding likely

17. 17 How do I start using SCA Policy? What are the decisions I need to make? What is an outline of the suggested steps? What policy language do I choose? What SCA implementation do I choose?

18. 18 How do I use RBAC with SCA Policy RBAC = Role Based Access Control Common method for authorization So common that special support was added for it with custom policy assertions: <runAs role=”xc:NCName” Example:

19. 19 What decisions do I need to make? Will you specify policy sets at development, or let them be determined at deployment? Will you use WS-Policy as your policy language? If no, then what will you use? If yes, do you need to extend it with custom assertions? What different policies will you need? Will you be able to get by with just the predefined intents, or will you need to add custom intents What are the governance processes for creating, modifying policies and policy sets?

20. 20 Suggested guidelines/profile Only specify intents at development time Keep your intents as abstract as possible (ideal)‏ Sometimes concrete intents (jms or xmpp.0080) are needed, but make sure they really are Use WS-Policy as your policy language, but... WS-Policy by itself is almost never enough, so decide which WS-Policy extensions you need to use If absolutely needed, roll you own assertion types Use policy inclusion to write small re-usable policy sets that are written by policy administrator with guidelines for assembler Use the broadest brush..if all the operations require confidentiality then put the confidentiality intent on the component

21. 21 What is an outline of suggested steps? List collaborations For each collaboration write the QoS characteristics required in abstract terms Refactor characteristics to eliminate redundancy List the binding types and implementations you will support Determine concrete requirements from the abstract characteristics for each binding type and implementation (revise characteristics if needed during this)‏ Captures abstract characteristics with existing intents if possible, create new ones if needed Determine what existing WS-Policy extensions are needed to express the concrete QoS requirements, if any If needed create a new WS-Policy extension (but first double check above to make sure you can't rework it so you don't need to roll your own)‏ Make sure your runtime supports your required extensions (rework as needed)‏ Turn areas of overlap among concrete QoS requirements into policy sets Use inclusion to create final policy sets, then tie them to intents Add intents to the components responsible for the matching collaboration

22. 22 What policy language do I use? Many policy languages to choose from SCA Policy built to support WS-Policy and others if desired Means best support is for WS-Policy Recommendation is to use WS-Policy with custom extensions if needed (they likely will be)‏

23. 23 What SCA Implementation do I use? Not many choices Of the 4 big ones (Oracle 11g, BEA AquaLogic, WebSphere, Tuscany), the first two are only available as beta right now. Supported versions of SCA policy are not known. Aqualogic has stated support for SCA with a policy aware SCA runtime for Weblogic server, and with AL Enterprise Repository, which will store SCA component assemblies and configuration Oracle 11g TP4 rumored to be imminent. SCA support in TP3 had pluses and minuses, including no Java SCA implementation components. Policy support is unknown. Websphere 6.1 SOA feature pack states support for SCA Policy 1.0 Apache Tuscany is Open Source with all he benefits and issues that entails, though it's under commercial-friendly Apache license Recommendation is, as always... code to the standard and try to stick to a version that's a little behind the bleeding edge, or a version that is already supported by the betas Test and provide SDKs using Open Source, with periodic integration tests with primary commercial choice and an alternative commercial choice. Demo and deploy with commercial products or Open Source, whichever one makes sense for your needs.

24. 24 What are some ideas for the future? A more robust set of policy intent domain extensions (but watch out for too tight coupling to concrete ideas) that fully specify intents for some domain Creating a mash-up of semantic reasoning and SCA with a runtime that translates to and provides for an alternate SCA description syntax that is compatible with semantic reasoning, such as XDI, RDF, or something else Policies change, a nice feature would be an optional use of a set of SCA components that provide policy store functionality for a SCA domain. This is necessary in environments where policy modifications occur frequently and are shared across many domains Other technologies that might make an interesting mash-up when combined with SCA: Web Ontology Language (OWL)‏ XACML WS-PolicyConstraints SAML ITU Policy standards (X.812/X.749)‏