8 Replies Latest reply: Jun 1, 2012 7:34 PM by David Ward RSS

Let's talk policy

Keith Babo Master

David and I had a brief chat about the Security Policy JIRA and figured it would be good to discuss in the community.  Here's the JIRA for reference:

 

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

 

What we need to implement for 0.5 is the first "stage" of that JIRA, satisfying the following basic use case:

 

  • Service provider declares that authentiation and/or confidentiality is required.
  • Service binding is configured to be consistent with the above policy.

 

Most of the pluming is in place for this bit.  We already have a generic policy handler which looks at the policy required by a service and the policy assertions that are present on an exchange.  The piece that remains is adding logic to gateway bindings to detect that authentication has taken place and/or if the transport was encrypted (e.g. SSL would satisfy the requirement for confidentiality).  As a first pass, I suggest we narrow our focus to SOAP gateway alone, so it's quite possible that the initial solution requires a change to SOAP gateway to check the transport type and authentication status.  Whether authentication was based on basic, digest, SSL client auth, or whatever else is not really our concern.  I'm guessing a simple query for the Principal or Subject might fit the bill.

 

Here's what transaction policy looks like:

 

 

        <component name="WorkService">
            <implementation.bean xmlns="urn:switchyard-component-bean:config:1.0" class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean"/>
            <service name="WorkService" requires="propagatesTransaction">
                <interface.java interface="org.switchyard.quickstarts.demo.policy.transaction.WorkService"/>
            </service>
        </component>

Security policy would look something like this:

 

 

         <component name="MyService">
            <implementation.bean xmlns="urn:switchyard-component-bean:config:1.0" class="org.switchyard.quickstarts.demo.policy.security.MyServiceBean"/>
            <service name="MyService" requires="authentication, confidentiality">
                <interface.java interface="org.switchyard.quickstarts.demo.policy.transaction.MyService"/>
            </service>
        </component>

 

Asserting that a policy is satisfied in the SOAP Gateway would look similar to this:

https://github.com/jboss-switchyard/components/blob/master/camel/camel-core/src/main/java/org/switchyard/component/camel/SwitchYardProducer.java#L84

 

Finally, if you want to read the background on SCA policy, that can be found below.  I wouldn't get lost in the spec though as what we are discussing here has a pretty narrow focus.

http://docs.oasis-open.org/opencsa/sca-policy/sca-policy-1.1-spec-csprd03.html#_Toc311121482

  • 1. Re: Let's talk policy
    David Ward Master

    I've got it all wired in, including junit tests. I use the WebServiceContext inside the soap component's InboundHandler to check to see if there's a user principal. If so, "clientAuthentication" has been fulfilled.  I also check the WebServiceContext's servletRequest, and if isSecure() is true, then "confidentiality" has been fulfilled.

     

    Working on a quickstart now...

     

    Just an FYI, according to the spec, there should be no commas in the value of the requires attribute.  The implementation in switchyard's policy framework doesn't add them. It's just a "bug" in the example above.

  • 2. Re: Let's talk policy
    Keith Babo Master

    You da man!

  • 3. Re: Let's talk policy
    David Ward Master

    And it appears "authentication" is deprecated, the favored replacement being "clientAuthentication" (which is different than "serverAuthentication" or "mutualAuthentication").  Right now I just support "clientAuthentication".  Should I add the deprecated "authentication" too?

  • 4. Re: Let's talk policy
    Keith Babo Master

    For now, it's cool to leave it out.  Only case I can see where it might be handy is if someone has an existing generator for SCDL that they want to use and it spits out authentication vs. clientAuthentication.  I think that's a pretty narrow case though.

  • 5. Re: Let's talk policy
    David Ward Master

    okee-dokee.

  • 6. Re: Let's talk policy
    Jeff DeLong Master

    Will this hook into JAAS and PicketLink? Have you thought about how authentication and authorization might be propogated between services? For an example of this in SOA-P 5.2, see SOA-P 5.2/samples/quickstarts/bpel_esb_hello_world_saml

  • 7. Re: Let's talk policy
    David Ward Master

    Jeff,

     

    Hooking into JAAS and PicketLink would be considered "stage 2".  Check out the description of the jira.

     

    At this point I honestly don't know what the level of effort would be for that.  Lemme finish "stage 1" (all that's left now is the quickstart), and then I'll look into it.

     

    David

  • 8. Re: Let's talk policy
    David Ward Master

    I just broke up the jira into 2:

    1. Stage 1: https://issues.jboss.org/browse/SWITCHYARD-725
    2. Stage 2: https://issues.jboss.org/browse/SWITCHYARD-830

    That way I can commit Stage 1 and people can start playing with it sooner, whilst I look into Stage 2.

     

    I believe Stage 1 is required for 0.5, and Stage 2 is not.  Doesn't mean Stage 2 won't be done in 0.5, but it kinda depends on the level of effort which I haven't looked into yet.