cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Mazza (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-4457) Extend WS-SecureConversation to support SAML Assertions for authentication
Date Sun, 16 Jun 2013 23:59:20 GMT

    [ 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

Mime
View raw message