RiftSaw
  1. RiftSaw
  2. RIFTSAW-190

BPELInvoke support WS Security / ESB Context

    Details

    • Type: Feature Request Feature Request
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 2.0-CR2
    • Fix Version/s: 2.2.0.CR1
    • Component/s: Integration
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      It would be great if the BPELInvoke activity could support the mapping of WS security information from the ESB Context into the message / variable associated with the receive operation. The use case requirement is:

      "A service implemented as a BPEL process requires authentication of a user. Composite services also require an authenticated user, and re-authentication should avoided. The customer wants to use WS-Security and SAML to fulfill this requirement"

      A possible solution is to expose the BPEL process services as an ESB Service via EBWS, and have the client consume this service using a WS-Security UsernameToken. This service would be configured like:

      <security moduleName="saml-issue-token" callbackHandler="org.jboss.soa.esb.services.security.auth.login.JBossSTSIssueCallbackHandler">
      </security>

      <actions mep="OneWay">
      <action name="startBPELProcessAction" class="org.jboss.soa.esb.actions.BPELInvoke">
      <property name="service" value="

      {http://www.jboss.org/bpel/examples/wsdl}

      HelloService"/>
      <property name="operation" value="hello" />
      <property name="requestPartName" value="TestPart" />
      </action>
      </actions>

      This security module will authenticate the user and create a SAML token via PicketLInk STS and place the token it in the ESB Context. The BPELInvoke action could then access the ESB Context to get the SAML Token, create a WS security element with this token, and add it to the request used to invoke ODE.

      The BPEL process WSDL would specify the use of the WS header element and the BPEL process designer would map the header element into variables and therefore outgoing message headers via assign / copy operations (similar to the hello_world_header_wsdl quickstart).

      This is a good use case for ESB / Riftsaw integration, as Riftsaw is able to use the ESB to access PicketLink and provide SAML support.

        Issue Links

          Activity

          Hide
          Gary Brown
          added a comment -

          Although not dependent upon WS-Security being available directly in RiftSaw, it would be better to provide after WS-Security was more generally available, which won't be until the 2.2.0 release.

          Show
          Gary Brown
          added a comment - Although not dependent upon WS-Security being available directly in RiftSaw, it would be better to provide after WS-Security was more generally available, which won't be until the 2.2.0 release.
          Hide
          Jeff DeLong
          added a comment -

          Gary,

          Your comments mentions WS-Security being available directly in Riftsaw in 2.2.0. What features / use cases would this provide? Are there JIRAs that describe that this JIRA could be linked to?

          Thanks,

          Jeff

          Show
          Jeff DeLong
          added a comment - Gary, Your comments mentions WS-Security being available directly in Riftsaw in 2.2.0. What features / use cases would this provide? Are there JIRAs that describe that this JIRA could be linked to? Thanks, Jeff
          Hide
          Gary Brown
          added a comment -

          Added link to RIFTSAW-75. There are three usecases - enabling BPEL processes to be secure, allowing BPEL processes to invoke secure web services, and finally to propagate security context through the BPEL process to invoked services. Currently these are being dealt with in the single issue - however if only some of these usecases can be delivered initially, then separate issues will be created for the remaining use cases.

          Show
          Gary Brown
          added a comment - Added link to RIFTSAW-75 . There are three usecases - enabling BPEL processes to be secure, allowing BPEL processes to invoke secure web services, and finally to propagate security context through the BPEL process to invoked services. Currently these are being dealt with in the single issue - however if only some of these usecases can be delivered initially, then separate issues will be created for the remaining use cases.
          Hide
          Jeff DeLong
          added a comment -

          I started a discussion on this topic on the design forum:

          https://community.jboss.org/thread/151873

          Show
          Jeff DeLong
          added a comment - I started a discussion on this topic on the design forum: https://community.jboss.org/thread/151873
          Hide
          Gary Brown
          added a comment -

          Not sure what should be added to the WS header. Using the security_saml ESB quickstart, the context contains:

          12:04:18,911 INFO [STDOUT] Subject in MyListenerAction : Subject:
          Public Credential: SamlCredential[<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns2="http://www.w3.org/2001/04/xmlenc#" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#" ID="ID_8a10190a-1733-4702-9413-47d2f0ef355f" IssueInstant="2010-10-06T11:04:17.699Z" Version="2.0"><Issuer>PicketLinkSTS</Issuer><Subject><NameID NameQualifier="urn:picketlink:identity-federation">admin</NameID><SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/></Subject><Conditions NotBefore="2010-10-06T11:04:17.699Z" NotOnOrAfter="2010-10-06T13:04:17.699Z"><AudienceRestriction><Audience>http://security_saml/goodbyeworld</Audience></AudienceRestriction></Conditions><dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/><dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/><dsig:Reference URI="#ID_8a10190a-1733-4702-9413-47d2f0ef355f" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/><dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">lS8akjeExG8nsYI8NyanfhpI4Mg=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>P50T2j81Tj2jRNoSqvn7G0muVWb7NrWN1Kj8+GN6q3QvPW/AE12fn5mXa7IMjR44WH0JKdsie/+l
          DyRQrvY2Oku+lr+BnDg4iEAj/MO4+YT9s2Kkj0Qc+qEW5gfHu4JLh6VKYAgHjqL8/kMk38dhEn3Y
          Z76rqLtMD+boav+s9NY=</dsig:SignatureValue><dsig:KeyInfo><dsig:KeyValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:RSAKeyValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Modulus xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">suGIyhVTbFvDwZdx8Av62zmP+aGOlsBN8WUE3eEEcDtOIZgO78SImMQGwB2C0eIVMhiLRzVPqoW1
          dCPAveTm653zHOmubaps1fY0lLJDSZbTbhjeYhoQmmaBro/tDpVw5lKJns2qVnMuRK19ju2dxpKw
          lYGGtrP5VQv00dfNPbs=</dsig:Modulus><dsig:Exponent xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue></dsig:KeyInfo></dsig:Signature></Assertion>]

          However https://jira.jboss.org/browse/SOA-2349 implies this information should not be exposed outside of the ESB service. So need guidance on what information should be passed to the BPEL process.

          Show
          Gary Brown
          added a comment - Not sure what should be added to the WS header. Using the security_saml ESB quickstart, the context contains: 12:04:18,911 INFO [STDOUT] Subject in MyListenerAction : Subject: Public Credential: SamlCredential[<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns2="http://www.w3.org/2001/04/xmlenc#" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#" ID="ID_8a10190a-1733-4702-9413-47d2f0ef355f" IssueInstant="2010-10-06T11:04:17.699Z" Version="2.0"><Issuer>PicketLinkSTS</Issuer><Subject><NameID NameQualifier="urn:picketlink:identity-federation">admin</NameID><SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/></Subject><Conditions NotBefore="2010-10-06T11:04:17.699Z" NotOnOrAfter="2010-10-06T13:04:17.699Z"><AudienceRestriction><Audience> http://security_saml/goodbyeworld </Audience></AudienceRestriction></Conditions><dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/><dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/><dsig:Reference URI="#ID_8a10190a-1733-4702-9413-47d2f0ef355f" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"/><dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">lS8akjeExG8nsYI8NyanfhpI4Mg=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>P50T2j81Tj2jRNoSqvn7G0muVWb7NrWN1Kj8+GN6q3QvPW/AE12fn5mXa7IMjR44WH0JKdsie/+l DyRQrvY2Oku+lr+BnDg4iEAj/MO4+YT9s2Kkj0Qc+qEW5gfHu4JLh6VKYAgHjqL8/kMk38dhEn3Y Z76rqLtMD+boav+s9NY=</dsig:SignatureValue><dsig:KeyInfo><dsig:KeyValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:RSAKeyValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Modulus xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">suGIyhVTbFvDwZdx8Av62zmP+aGOlsBN8WUE3eEEcDtOIZgO78SImMQGwB2C0eIVMhiLRzVPqoW1 dCPAveTm653zHOmubaps1fY0lLJDSZbTbhjeYhoQmmaBro/tDpVw5lKJns2qVnMuRK19ju2dxpKw lYGGtrP5VQv00dfNPbs=</dsig:Modulus><dsig:Exponent xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue></dsig:KeyInfo></dsig:Signature></Assertion>] However https://jira.jboss.org/browse/SOA-2349 implies this information should not be exposed outside of the ESB service. So need guidance on what information should be passed to the BPEL process.
          Hide
          Jeff DeLong
          added a comment -

          My thought on this was to use the ESB to request the SAML Token from PicketLInk STS when invoking services in a BPEL process. So an ESB Service would be created with a security moduleName = "saml-issue-token" followed by the BPELInvoke action, and the BPEL Invoke action would extract the SAML Token form the JAAS subject, and place it in the SOAPHeader (or variable associated with the receive activity), where it could then be copied into other variables.

          So what should not be exposed outside the ESB is the JAAS subject. Instead the SAML Token should be extracted and used.

          Show
          Jeff DeLong
          added a comment - My thought on this was to use the ESB to request the SAML Token from PicketLInk STS when invoking services in a BPEL process. So an ESB Service would be created with a security moduleName = "saml-issue-token" followed by the BPELInvoke action, and the BPEL Invoke action would extract the SAML Token form the JAAS subject, and place it in the SOAPHeader (or variable associated with the receive activity), where it could then be copied into other variables. So what should not be exposed outside the ESB is the JAAS subject. Instead the SAML Token should be extracted and used.
          Hide
          Babak Mozaffari
          added a comment -

          I seem to not have the proper permissions to view SOA-2349 so I'm not sure what information should not be exposed outside of the ESB service and why. I agree with Jeff in that the SAML token would typically be held by a caller intending to do SSO. It is sensitive information in that it provides the caller (and potential snoopers) with access to a service and it would therefore make sense for it to be transferred through secured means such as SSL, but that is no different than login credentials used to obtain this token in the first place, which are even more sensitive.

          Show
          Babak Mozaffari
          added a comment - I seem to not have the proper permissions to view SOA-2349 so I'm not sure what information should not be exposed outside of the ESB service and why. I agree with Jeff in that the SAML token would typically be held by a caller intending to do SSO. It is sensitive information in that it provides the caller (and potential snoopers) with access to a service and it would therefore make sense for it to be transferred through secured means such as SSL, but that is no different than login credentials used to obtain this token in the first place, which are even more sensitive.

            People

            • Assignee:
              Gary Brown
              Reporter:
              Jeff DeLong
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: