gt; View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Security-policy-signature-method-tp5732250p5760265.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
this message in context:
http://cxf.547215.n5.nabble.com/CXF-Security-policy-signature-method-tp5732250p5760265.html
Sent from the cxf-user mailing list archive at Nabble.com.
igestAlgorithm(SignatureConstants.ALGO_ID_DIGEST_SHA256);
>
> The SignatureMethod alg is still "rsa-sha1" and the DigestMethod alg is
> "sha1". No errors reported it's just not using the set algorithm.
> Unrestricted policies in place. Not sure what I am still missing
not using the set algorithm.
Unrestricted policies in place. Not sure what I am still missing -Jeff
--
View this message in context:
http://cxf.547215.n5.nabble.com/CXF-Security-policy-signature-method-tp5732250p5760065.html
Sent from the cxf-user mailing list archive at Nabble.com.
CXF-3.1.0 and I was hoping the ability to
> override SHA-1 was now available and if so how can I do it.
>
> Thanks!
> -Jeff
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-Security-policy-signature-method-tp5732250p5760020.html
>
!
-Jeff
--
View this message in context:
http://cxf.547215.n5.nabble.com/CXF-Security-policy-signature-method-tp5732250p5760020.html
Sent from the cxf-user mailing list archive at Nabble.com.
Yes, you could try overriding the default AlgorithmSuite. See this blog
post for more information:
http://coheigea.blogspot.ie/2011/09/specifying-custom-algorithmsuite.html
Colm.
On Tue, Aug 13, 2013 at 2:48 PM, Ted Roeloffzen wrote:
> Thank you for creating the JIRA.
>
> In this case i'm scre
Thank you for creating the JIRA.
In this case i'm screwed i think.
As far as I know, RSA-SHA256 is mandatory for this service to work.
Is there a to work around it?
Is there a class that I can inherit from to make it work?
Ted
2013/8/13 Colm O hEigeartaigh
> SHA-256 is only used for the dig
SHA-256 is only used for the digest algorithm for any of the standard
WS-SecurityPolicy AlgorithmSuites. The Signature Algorithm is always
RSA-SHA1 and cannot be configured. Ideally, we would have a new
specification to cater for newer security algorithms, but this does not
appear likely from my un
I was afraid of that.
The policy that is used is as follows:
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
You can't set the SignatureAlgorithm if you are using WS-SecurityPolicy, as
it defaults to that of the spec. What requirements do you have? What
signature algorithm do you want to use?
Colm.
On Tue, Aug 13, 2013 at 1:36 PM, Ted Roeloffzen wrote:
> Hi Colm,
>
> The WSS4JOutInterceptor is created
Hi Colm,
The WSS4JOutInterceptor is created and configured automatically by CXF,
right?
Can I somehow retrieve the WSS4JOutInterceptor during the process and set
the signatureAlgorithm tag, without having to configure the entire
interceptor?
Ted
2013/8/13 Colm O hEigeartaigh
> If you are us
If you are using WS-SecurityPolicy, then the spec defines the signature
method as "RSA-SHA1" for Asymmetric Signature, and "HMAC-SHA1" for
Symmetric Signature. Otherwise, you can set it via the "signatureAlgorithm"
configuration tag on the WSS4JOutInterceptor.
Colm.
On Tue, Aug 13, 2013 at 8:08
Hi All,
How does CXF determine which signature method to use?
Does it retrieve it from the security-policy in the WSDL or do you have to
configure it?
kind regards,
Ted
ntext:
http://cxf.547215.n5.nabble.com/Debugging-in-CXF-security-WSS4JInInterceptor-WSS4JOutInterceptor-returning-exceptions-through-service-tp5534346p5534346.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
:
http://cxf.547215.n5.nabble.com/Debugging-in-CXF-security-WSS4JInInterceptor-WSS4JOutInterceptor-returning-exceptions-through-service-tp5534346p5534346.html
Sent from the cxf-user mailing list archive at Nabble.com.
tificates if
you plan on working with them in production.
Glen
fachhoch wrote:
>
> please tell me why do we need a self signed keystore , it works without
> self signing , please tell me what is purpose of self signing
>
--
View this message in context:
http://cxf.547215.n5.na
please tell me why do we need a self signed keystore , it works without self
signing , please tell me what is purpose of self signing
--
View this message in context:
http://cxf.547215.n5.nabble.com/cxf-security-tp2848487p2850172.html
Sent from the cxf-user mailing list archive at Nabble.com.
find the same key so request is processed.
> Now I heard about selfcert a certificate what is this? do I have to do
> this ?
>
--
View this message in context:
http://cxf.547215.n5.nabble.com/cxf-security-tp2848487p2849902.html
Sent from the cxf-user mailing list archive at Nabble.com.
what is this? do I have to do
this ?
--
View this message in context:
http://cxf.547215.n5.nabble.com/cxf-security-tp2848487p2848487.html
Sent from the cxf-user mailing list archive at Nabble.com.
On 2010/06/18 22:21, Daniel Kulp wrote:
> On Thursday 17 June 2010 11:17:13 pm Nikolay Elenkov wrote:
>>
>> So I guess we are safe. Anyone that built using Maven should get the same,
>> so it should be mostly OK? Unless of course their appserver ignores the
>> bundled parser and uses the system on
On Thursday 17 June 2010 11:17:13 pm Nikolay Elenkov wrote:
> Apparently 2.2.7 has the Woodstox parser as a dependency, and for the above
> request that gives a (on Tomcat 5.5)
>
> http://schemas.xmlsoap.org/soap/envelope/";>
>
>
> soap:Client
> Error reading XMLStreamReader.
>
>
>
>
> W
On 2010/06/17 22:17, Daniel Kulp wrote:
> On Wednesday 16 June 2010 10:00:03 pm Nikolay Elenkov wrote:
>> On 2010/06/17 0:29, Daniel Kulp wrote:
>>> The Apache CXF team recently discovered a security issue that may allow
>>> an attacker to carry out denial of service attacks and to read arbitrary
>
On Wednesday 16 June 2010 10:00:03 pm Nikolay Elenkov wrote:
> On 2010/06/17 0:29, Daniel Kulp wrote:
> > The Apache CXF team recently discovered a security issue that may allow
> > an attacker to carry out denial of service attacks and to read arbitrary
> > files on the file system of the node whe
On 2010/06/17 0:29, Daniel Kulp wrote:
>
>
> The Apache CXF team recently discovered a security issue that may allow an
> attacker to carry out denial of service attacks and to read arbitrary files
> on
> the file system of the node where CXF runs. Details of the vulnerability are
> described
The Apache CXF team recently discovered a security issue that may allow an
attacker to carry out denial of service attacks and to read arbitrary files on
the file system of the node where CXF runs. Details of the vulnerability are
described in the following advisory:
http://svn.apache.org/rep
Hi everyone
"Note that the nonce support recommended by the specification for
guarding against replay attacks has not yet been implemented either in
CXF or WSS4J." (from
http://cwiki.apache.org/CXF20DOC/ws-security.html)
Is this still true?
Thank you very much
Best regards
I guess it depends on how strict the security manager is. CXF, but it's
nature, does a lot of things with reflection, examining annotations, etc...
It also does some classloading things, it uses ASM to create some classes,
etc... There are a bunch of things that could potentially cause is
Thanks, Sergey ...
It's very hard to say, actually.
The situation is that I'm making the CXF call from within a GWT
(Google Web Toolkit) servlet. The CXF call is throwing an exception
(Throwable, as far as I know), and when I try to forward the
exception or do anything with it, something very
Hi
Hi --
I have a Tomcat-based application that is able to perform a CXF-based
web services call just fine when Tomcat security is turned off. When
Tomcat security is on, the CXF-based web service call throws an
execution error exception.
I assume that this occurs because I haven't provi
Hi --
I have a Tomcat-based application that is able to perform a CXF-based
web services call just fine when Tomcat security is turned off. When
Tomcat security is on, the CXF-based web service call throws an
execution error exception.
I assume that this occurs because I haven't provided som
I guess the question is: what do you WANT to happen if the authentication
fails?
An incoming custom interceptor really could do anything you want. You can
validate the user and if it's not correct, pause/stop the current chain, grab
the response conduit, and write out any type of response
Resending without the cert .
I'm implementing a web service with security authentication (using plain
text password passed in and a custom password handler callback). Everything
works fine except for the fact that when a login/password fails
authentication, the only resort is to throw a WSSecur
in the same manner.
Glen
[1]
http://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-UsernameTokenAuthentication
--
View this message in context:
http://www.nabble.com/CXF-security-without-throwing-exceptions-tp19227328p19229365.html
Sent from the cxf-user mailing list archive at Nabble.com.
I would look at implementing a web service called
validateUser or whatever that returns true/false based on successful or
failed authentication.
Glen
--
View this message in context:
http://www.nabble.com/CXF-security-without-throwing-exceptions-tp19227328p19228698.html
Sent from the cxf-user mailing
I'm implementing a web service with security authentication (using plain
text password passed in and a custom password handler callback). Everything
works fine except for the fact that when a login/password fails
authentication, the only resort is to throw a WSSecurityException or
SoapFault. Given
36 matches
Mail list logo
