Policy Support in the Editor

[bfitzpat]

I've started looking at how to support SWITCHYARD-950 in the editor, which adds policy support to the editor.

Based on the documentation (https://docs.jboss.org/author/display/SWITCHYARD/Policy), it looks like we need the ability to specify a few things as properties on a component service:

• The Transaction Policy can be set for a component service to: propagatesTransaction or suspendsTransaction, which is added to the "requires" attribute. (i.e. "<service name="WorkService" requires="propagatesTransaction">"). This is optional in the configuration file and may also be specified in the service implementation via a @Requires annotation (i.e. "@Requires(transaction = TransactionPolicy.PROPAGATES_TRANSACTION)"),
• The Security Policy (which may involve changes once David is done) is also set for a component service. The config can specify "clientAuthentication" and/or "confidentiality" in the requires attribute (i.e. "<service name="WorkService" requires="clientAuthentication, confidentiality">"). Again, this is optional, and may be specified via the @Requires annotation in the service implementation (i.e. "@Requires(security = {SecurityPolicy.CLIENT_AUTHENTICATION, SecurityPolicy.CONFIDENTIALITY})").

It appears that the transaction policy is limited to the bean implementation and JMS endpoints in the Camel gateway (binding).

And security policy is limited to the bean implementation and the SOAP endpoint in the SOAP gateway (binding). (And this may be changing due to David's work with the security handling.)

I have a few questions:

1. What quickstarts should I look at for examples of these policy properties?
2. How visible should these properties be? I'm thinking of just adding a "Policy" property page for component services that shows available options where supported or disables the controls if not.
3. Can the user use one or the other of the security policy options? Or is it a requirement that both be used? I'm looking at checkboxes for the client authentication and confidentiality options.
4. Transaction policy will likely become a new drop-down list (so the user can clear the selection or select propagates or suspends transaction).
5. Are more policies going to be added in the future? Any thoughts on how much room for customization should be here?

Thanks in advance for any and all help!

[igarashitm]

Hi Brian,

Transaction Policy now can be the combination of following two types, both of them are optional though.

• Interaction Policy (we already has after Stage1)
  • propagatesTransaction
  • suspendsTransaction
• Implementation Policy (was added at Stage2)
  • managedTransaction.Global
  • noManagedTransaction

And we will have Stage3 - the Interaction Policy should be able to be applied to the reference as well. In addition, managedTransaction.Local may be added to the Implementation Policy.

In addition to the Camel JMS, JCA inflow also can provide Transaction policy. And we can specify Transaction Policy on all type of service implementations.

I think that's all for Transaction Policy... SCA spec allows to specify those policies on composite, composite service/reference, and component service/reference, but I'm not sure how will we handle those in the future.

Thanks,

Tomo

[bfitzpat]

Thanks Tomo. Do we have any quickstarts that demonstrate Stage 1 and Stage 2? Can they mix and match?

[igarashitm]

quickstarts/demos/policy-transaction demonstrates the usage coming from Stage1, but none for Stage2 right now... Sorry, I should have added.

https://issues.jboss.org/browse/SWITCHYARD-997

We can specify the combination of Interaction Policy and Implementation Policy. For example

• requires="propagatesTransaction managedTransaction.Global" means the service should propagate the transaction which is passed by the client during invocation
• requires="suspendsTransaction managedTransaction.Global" means the service should suspends the transaction which is passed by the client, and manage(start/complete) new global transaction during invocation
• requires="suspendsTransaction noManagedTransaction" means the service should suspends the transaction which is passed by the client during invocation

[bfitzpat]

Can we mix and match security requires flags with these flags?

<service name="WorkService" requires="clientAuthentication, confidentiality, propagatesTransaction managedTransaction.Global">

Should there be commas between the "propagatesTransaction managedTransaction.Global" flags?

[igarashitm]

Yep, security & transaction policy should be able to be mixed.

I think required policy is parsed and splitted with blank here:

https://github.com/jboss-switchyard/core/blob/master/config/src/main/java/org/switchyard/config/model/composite/v1/PolicyConfig.java#L49

security policy allows comma?

[bfitzpat]

David just confirmed that the docs were out of date and it should be spaces as the delimiter. So I think it's all good.

I'll see what I can come up with as far as UI now.

[dward]

quickstarts/demos/policy-security has been changed on SWITCHYARD-830 to policy-security-sslbasicauth, and a new quickstart was added too: policy-security-sslsaml2.  When the branch moves, I will ping you a reminder.

clientAuthentication (basicauth, saml2) and confidentiality (ssl) can be used separately or together, and also mixed with the transaction policies.

At a minimum on SWITCHYARD-830, the soap and http components will be able to feed those policies, however I'm also trying to get the resteasy component included as well.  Again, I'll letcha know.

[bfitzpat]

This is what I have at this point. None of the options are required.

My question (still a little vague, sorry) is this...

* Security Policy options should only be availble on composite services or composite references with SOAP, HTTP, or REST bindings?

* Transaction Policy options should be available on component services or component references for all service implementations as well as composite services with Camel JMS and JCA inbound bindings.

This seems a bit haphazard at this point. Am I close? Not even? Is there a method to the madness of where policy should be able to be set?

[rcernich]

Hey Brian,

I think it would be better to follow the UI paradigm you're using with bindings.  Policies may be applied to the service and the list of possible policies may grow (and could even include user defined policies).  It may be better to have an "add policy" which would include the set of known policies not already configured on the object (e.g. transaction, security, etc.).  You'd then have your separate little editing area where the details specific to the type of policy may be configured.

Just my two cents.

Best,

Rob

[bfitzpat]

Based on what I've seen in the docs and in the quickstarts, there's nothing to configure. You're merely setting a named flag in the "requires" attribute of a component service declaration in the configuration file. There may be additional work to be done in the service implementation class, but that's handled outside the configuration editor.

If we need to add the ability to specify custom policies in the future, we can perhaps open it up to allow free-form editing of that "requires" content, but at this point that doesn't seem possible.

The only difference at this point is that some of the properties are either/or and others are and/or, so that's why I'm going with a drop-down list.

My goal is to make it as simple as it needs to be. If it needs to be more complex, then we'll make it so.

[rcernich]

Right.  But, that "requires" field is actually a list, so you're adding and removing items from that list when you're editing the policies.  Some of those policies fall into the scopes you've provided (transaction, security) and some of those items may be exclusive to other items (e.g. supsends vs. propagates).

If we're going to break things out, I think I'd prefer to see a separate tab for "Transactions" and "Security."

If you haven't already, you may want to browse Pluggable PolicyProviders to see how that might affect things in the future.

Just ideas.  Do with them what you will.

Best,

Rob

[dward]

Rob, FYI - I have removed the notion of Pluggable Policy Providers.  So, instead of a <policy-providers> section under <domain>, there is simply a <security name="" provider=""/> element (optional, and both attributes optional).  I'll explain more when SWITCHYARD-830 (finally) moves.

Unfortunately, you're dealing with stuff that's still in flux. Sorry...

[rcernich]

Sorry about that.  Just ignore me.

"These aren't the droids you're looking for..."

[bfitzpat]

Rob, I think the idea of splitting things up is a good idea. I've been pondering dividing up Security Policy and Transactional Policy into separate tabs anyway, since they can apply to different parts of the model it seems.