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

1 Policy-Enabling the SCA-based SOA

Embed Size (px)

Citation preview

Page 1: 1 Policy-Enabling the SCA-based SOA

1

Policy-Enabling the SCA-based SOA

www.oasis-open.org

Page 2: 1 Policy-Enabling the SCA-based SOA

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

Page 3: 1 Policy-Enabling the SCA-based SOA

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

Page 4: 1 Policy-Enabling the SCA-based SOA

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

Page 5: 1 Policy-Enabling the SCA-based SOA

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

Page 6: 1 Policy-Enabling the SCA-based SOA

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?

Page 7: 1 Policy-Enabling the SCA-based SOA

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?

Page 8: 1 Policy-Enabling the SCA-based SOA

8

Intent Example

- From the SCA Policy Overview webinar

<intent name="sca:messageProtection" constrains="sca:binding" requires="sca:confidentiality sca:integrity">

<description> Protect messages from unauthorized reading or modification.

</description></intent>

Page 9: 1 Policy-Enabling the SCA-based SOA

9

Policy set example (using WS-Policy)

<policySet name="sca:userNameTokenHashPassword" provides="sca:authentication" appliesTo="sca:binding.ws">

<wsp:Policy> <sp:SupportingToken> <wsp:Policy> <sp:UserNameToken> <wsp:Policy> <sp:HashPassword> </wsp:Policy> </sp:UserNameToken> </wsp:Policy> </sp:SupportingToken> </wsp:Policy></policySet>

- From the SCA Policy Overview webinar

Page 10: 1 Policy-Enabling the SCA-based SOA

10

A 2nd policy example (not WS-Policy)

<policySet provides="sns:logging.trace" appliesTo="sca:implementation.bpel">

<acme:processLogging level="3"/></policySet>

Page 11: 1 Policy-Enabling the SCA-based SOA

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

Page 12: 1 Policy-Enabling the SCA-based SOA

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

Page 13: 1 Policy-Enabling the SCA-based SOA

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.

Page 14: 1 Policy-Enabling the SCA-based SOA

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

Page 15: 1 Policy-Enabling the SCA-based SOA

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

Page 16: 1 Policy-Enabling the SCA-based SOA

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.ws> binding,

which requires the use of WS-Addressing with anonymous responses (e.g. <wsaw:Anonymous>required</wsaw:Anonymous>”

BP.1_1 WS-BasicProfile is followed, ws binding likely

Page 17: 1 Policy-Enabling the SCA-based SOA

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?

Page 18: 1 Policy-Enabling the SCA-based SOA

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: <allow roles=”list of NCNames” /> <permitAll> <denyAll> <runAs role=”xc:NCName”

Example:

<policySet name=”allow_customers”>

<allow roles=”customers” />

</policySet>

Page 19: 1 Policy-Enabling the SCA-based SOA

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?

Page 20: 1 Policy-Enabling the SCA-based SOA

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

Page 21: 1 Policy-Enabling the SCA-based SOA

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

Page 22: 1 Policy-Enabling the SCA-based SOA

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)

Page 23: 1 Policy-Enabling the SCA-based SOA

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.

Page 24: 1 Policy-Enabling the SCA-based SOA

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)