[
https://issues.apache.org/jira/browse/CXF-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685458#comment-13685458
]
Glen Mazza commented on CXF-4457:
---------------------------------
OK, Colm, this issue can now be closed IMO, it works. Remaining comments:
1.) I realize it doesn't matter, but it looks sort of silly for them to be out
of sync, and may cause users to be concerned that there is a bug in the code.
If it's easy to fix, I would do so, but no biggie.
2.) Based on my limited understanding of SecureConversation (namely, one IBM
developerWorks article), the secure conversation call is only between the WSC
and WSP, the WSC requests the SCT from the WSP (using a SAML token obtained by
the STS) and not the STS. AFAICT, the STS should therefore be oblivious to the
fact that secure conversation is being used between the WSC and WSP, and so the
client-side config w.r.t the STS shouldn't need changing for this. Stated
another way, is there any reasonable use case for defining *both* a <entry
key="ws-security.sts.client"> and a <entry key="ws-security.sts.client.sct">
for the same jaxws:client? If the answer is "no", perhaps consolidating the
two in Apache 3.0 would be a good idea.
3.) If there's no realistic use case to splitting out the .sct for the
service-side keystore/properties configuration, I would consider consolidating
the two (i.e., get rid of the .sct setting) in Apache CXF 3.0. This will help
make CXF work more smoothly OOTB with whatever the security policy statements
say.
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
