[
https://issues.apache.org/jira/browse/CXF-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684850#comment-13684850
]
Glen Mazza commented on CXF-4457:
---------------------------------
Hi Colm, it works, but...
1.) Look at line 604-605 here (1st SOAP call from WSC to WSP *after* SCT
obtained from WSP):
https://gist.github.com/gmazza/5793846#file-cxfstswssecureconversation-xml-L604-L605
There's an inconsistency between the Id value chosen and the actual identifier.
2.) Why should I have to change the client-side cxf.xml from
"ws-security.sts.client" to
"ws-security.sts.client.sts" as a result of activating WS-SecureConversation
between the WSC and WSP? After all, the WSC still gets the same SAML token
from the STS regardless
(correct?), it's just that the WSC makes one extra call to the WSP before
making the DoubleIt calls
to get an SCT using that SAML token. Can't (shouldn't) the
"ws-security.sts.client" key remain
the same? It doesn't seem very WS-Policy-like, i.e., it seems the client is
determining policy not from
reading the WSDL but from the configuration in the cxf.xml.
3.) Likewise, on the WSP's cxf-servlet.xml, this is the configuration if I'm
not using
WS-SecureConversation:
<entry key="ws-security.callback-handler"
value="service.ServiceKeystorePasswordCallback"/>
<entry key="ws-security.signature.properties"
value="serviceKeystore.properties"/>
...and if I am:
<entry key="ws-security.callback-handler.sct"
value="service.ServiceKeystorePasswordCallback"/>
<entry key="ws-security.signature.properties.sct"
value="serviceKeystore.properties"/>
I don't know if this would open up a can of worms, but can't we just rely on
the non-".sct" versions
in either case--what are the benefits to splitting them out?
Overall, Metro doesn't require any configuration change besides changing the
WSDL's Policy statements to add/remove WS-SecConv; I am wondering if it would
be beneficial for CXF to behave the same.
Thanks!
Glen
> Extend WS-SecureConversation to support SAML Assertions for authentication
> --------------------------------------------------------------------------
>
> Key: CXF-4457
> URL: https://issues.apache.org/jira/browse/CXF-4457
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Reporter: Glen Mazza
> Assignee: Colm O hEigeartaigh
> Attachments: cxf-tutorial.patch
>
>
> Hi, as shown for GlassFish Metro:
> https://gist.github.com/3191480
> Support the following authentication mechanism:
> 1.) The WSC gets a SAML assertion from the STS.
> 2.) The WSC sends that SAML assertion to the WSP to get the SCT from the WSP
> 3.) All subsequent real calls for doubled numbers between WSC and WSP use the
> SCT and not the SAML assertion.
> Here is a Netbeans-generated WSDL for this scenario:
> https://github.com/gmazza/blog-samples/blob/master/cxf_sts_tutorial/service/src/main/resources/DoubleItSecrConv.txt
> A sample testcase that can be used (steps to use: update WSP WSDL with the
> one above, run mvn clean install tomcat7:redeploy from base folder, then mvn
> exec:exec from client folder):
> https://github.com/gmazza/blog-samples/tree/master/cxf_sts_tutorial
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
