[
https://issues.apache.org/jira/browse/CXF-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685871#comment-13685871
]
Glen Mazza commented on CXF-4457:
---------------------------------
Speaking only about #3 (not commenting one way or the other on #2), I'm not
sure if backwards compatibility is a concern. Presently, if you're using
WS-SecConv but you've only configured the non-SCT versions in cxf-servlet.xml,
there's no way your WSP would be accepting any SOAP calls anyway--you'd have a
nonfunctioning system. So I don't see the harm in allowing WS-SecConv to use
the non-.sct version in a new version of CXF. OTOH, if you do explicitly
configure an .sct version, I would say that and only that version should be
read, and that the non-.sct version should be ignored in that case.
> 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
