1 2 Previous Next 20 Replies Latest reply on Aug 29, 2012 9:39 AM by Brian Fitzpatrick

    Policy Support in the Editor

    Brian Fitzpatrick Expert

      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!

        • 1. Re: Policy Support in the Editor
          Tomohisa igarashi Master

          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

          1 of 1 people found this helpful
          • 2. Re: Policy Support in the Editor
            Brian Fitzpatrick Expert

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

            • 3. Re: Policy Support in the Editor
              Tomohisa igarashi Master

              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
              1 of 1 people found this helpful
              • 4. Re: Policy Support in the Editor
                Brian Fitzpatrick Expert

                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?

                • 5. Re: Policy Support in the Editor
                  Tomohisa igarashi Master

                  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?

                  • 6. Re: Policy Support in the Editor
                    Brian Fitzpatrick Expert

                    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.

                    • 7. Re: Policy Support in the Editor
                      David Ward Master

                      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.

                      • 8. Re: Policy Support in the Editor
                        Brian Fitzpatrick Expert

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

                        policy-property-page.png

                        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?

                        • 9. Re: Policy Support in the Editor
                          Rob Cernich Master

                          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

                          • 10. Re: Policy Support in the Editor
                            Brian Fitzpatrick Expert

                            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.

                            • 11. Re: Policy Support in the Editor
                              Rob Cernich Master

                              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

                              • 12. Re: Policy Support in the Editor
                                David Ward Master

                                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...

                                • 13. Re: Policy Support in the Editor
                                  Rob Cernich Master

                                  Sorry about that.  Just ignore me.

                                   

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

                                  • 14. Re: Policy Support in the Editor
                                    Brian Fitzpatrick Expert

                                    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.

                                    1 2 Previous Next