OASIS - Policy-Enabling the SCA-based SOA

watermelonroachdaleInternet και Εφαρμογές Web

30 Ιουλ 2012 (πριν από 5 χρόνια και 3 μήνες)

388 εμφανίσεις

1

Policy
-
Enabling the SCA
-
based SOA



www.oasis
-
open.org

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

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

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

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

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


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

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>

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


10

A
2
nd

policy example (not WS
-
Policy)


<
policySet
provides
=
"sns:logging.trace"


appliesTo
=
"sca:implementation.bpel"
>


<
acme:processLogging
level
=
"3"
/>

</
policySet
>

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

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

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

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

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

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

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

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>

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

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

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

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

What SCA Implementation do I use?


Not many choices


Of the
4
big ones (Oracle
11
g, 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
11
g TP
4
rumored to be imminent. SCA support in TP
3
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

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
)