You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2012/12/04 13:06:43 UTC
Re: Container validation of UsernameToken passwords?
I don't think there is a way to handle this at the moment. You could plug
in a custom Validator for (WS-Security) UsernameTokens and do some
container-specific validation I guess.
Colm.
On Fri, Nov 30, 2012 at 4:51 PM, Glen Mazza <gl...@gmail.com> wrote:
> Hi folks, I just confirmed by testing Metro w/UsernameToken over SSL
> transport (haven't tried UT via their symmetric binding yet), that if I
> *don't* configure a server-side password callback handler like here:
>
> https://github.com/gmazza/blog-samples/blob/master/metro_usernametoken_profile/service/src/main/resources/DoubleIt.wsdl#L89
> , Metro transparently switches to container validation instead -- in my
> case, the tomcat-users.xml file:
> http://www.jroller.com/gmazza/entry/ssl_for_web_services#SSL5 . The
> validation appears to be the same validation done with SSL with basic
> authentication, i.e., checking that the username and password exists within
> the roles defined in the web.xml in the WAR hosting the web service.
> Having
> not yet debugged the Metro source code, I'm not sure whether Metro is
> hardcoded to be able to handle only GlassFish and Tomcat or can generically
> do container validation with any servlet container (I would suspect the
> latter), or what it would do for OSGi environments for that matter.
>
> Is there a way to do this right now with CXF? CXF raises "General security
> error (WSSecurityEngine: No password callback supplied)" if I don't provide
> a server-side password callback handler as here:
>
> https://github.com/gmazza/blog-samples/blob/master/cxf_usernametoken_profile/war/src/main/webapp/WEB-INF/cxf-servlet.xml#L19
> .
> If not, I'm not sure if it's worth implementing--I guess it's a question of
> how much additional benefit it would provide, the amount of effort it would
> take to do so in a generic fashion, and risk of security vulnerabilities.
>
> Regards,
> Glen
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Container-validation-of-UsernameToken-passwords-tp5719516.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Container validation of UsernameToken passwords?
Posted by Sergey Beryozkin <sb...@gmail.com>.
This is why using JAAS is better :-)
Cheers, Sergey
On 15/12/12 00:17, Glen Mazza wrote:
> OK, I just debugged the Metro source code to determine how they can read the
> Tomcat tomcat-users.xml file in order to do validation of UsernameToken
> passwords.
>
> Basically, if no sc:ValidatorConfiguration defined in the service-side WSDL:
> https://github.com/gmazza/blog-samples/blob/master/metro_usernametoken_profile/service/src/main/resources/DoubleIt.wsdl#L89
>
> Then, the conditional at Metro's
> DefaultSecurityEnvironmentImpl.authenticateUser() line #1167 will not be
> met:
> http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.metro/webservices-rt/2.2.1-1/com/sun/xml/wss/impl/misc/DefaultSecurityEnvironmentImpl.java#1167
>
> ...and hence the line at 1173 (to check the Tomcat password file) is done
> instead, in class DefaultRealmAuthenticationAdapter.authenticate():
> http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.metro/webservices-rt/2.2.1-1/com/sun/xml/wss/impl/misc/DefaultRealmAuthenticationAdapter.java#DefaultRealmAuthenticationAdapter.authenticate%28javax.security.auth.Subject%2Cjava.lang.String%2Cjava.lang.String%29
>
> As you can see from the above class, Metro can do this for Tomcat and
> GlassFish only, not all servlet containers; furthermore it just relies on
> system variables to hunt down the location of the tomcat-users.xml and read
> usernames and passwords from it. (For GlassFish, as shown in that same
> class, it attempts to load a GlassFish callback handler of some sort,
> instead of reading a file.)
>
> Glen
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Container-validation-of-UsernameToken-passwords-tp5719516p5720335.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Container validation of UsernameToken passwords?
Posted by Glen Mazza <gl...@gmail.com>.
OK, I just debugged the Metro source code to determine how they can read the
Tomcat tomcat-users.xml file in order to do validation of UsernameToken
passwords.
Basically, if no sc:ValidatorConfiguration defined in the service-side WSDL:
https://github.com/gmazza/blog-samples/blob/master/metro_usernametoken_profile/service/src/main/resources/DoubleIt.wsdl#L89
Then, the conditional at Metro's
DefaultSecurityEnvironmentImpl.authenticateUser() line #1167 will not be
met:
http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.metro/webservices-rt/2.2.1-1/com/sun/xml/wss/impl/misc/DefaultSecurityEnvironmentImpl.java#1167
...and hence the line at 1173 (to check the Tomcat password file) is done
instead, in class DefaultRealmAuthenticationAdapter.authenticate():
http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.metro/webservices-rt/2.2.1-1/com/sun/xml/wss/impl/misc/DefaultRealmAuthenticationAdapter.java#DefaultRealmAuthenticationAdapter.authenticate%28javax.security.auth.Subject%2Cjava.lang.String%2Cjava.lang.String%29
As you can see from the above class, Metro can do this for Tomcat and
GlassFish only, not all servlet containers; furthermore it just relies on
system variables to hunt down the location of the tomcat-users.xml and read
usernames and passwords from it. (For GlassFish, as shown in that same
class, it attempts to load a GlassFish callback handler of some sort,
instead of reading a file.)
Glen
--
View this message in context: http://cxf.547215.n5.nabble.com/Container-validation-of-UsernameToken-passwords-tp5719516p5720335.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Container validation of UsernameToken passwords?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Will configuring WSS4JInInterceptor to skip validating the token
("ws-security.validate.token" property set to false) and using
JAASLoginInterceptor do it ?
http://cxf.apache.org/docs/security.html#Security-JAASLoginInterceptor
This path might work for UT only I guess
Cheers, Sergey
On 04/12/12 12:06, Colm O hEigeartaigh wrote:
> I don't think there is a way to handle this at the moment. You could plug
> in a custom Validator for (WS-Security) UsernameTokens and do some
> container-specific validation I guess.
>
> Colm.
>
> On Fri, Nov 30, 2012 at 4:51 PM, Glen Mazza<gl...@gmail.com> wrote:
>
>> Hi folks, I just confirmed by testing Metro w/UsernameToken over SSL
>> transport (haven't tried UT via their symmetric binding yet), that if I
>> *don't* configure a server-side password callback handler like here:
>>
>> https://github.com/gmazza/blog-samples/blob/master/metro_usernametoken_profile/service/src/main/resources/DoubleIt.wsdl#L89
>> , Metro transparently switches to container validation instead -- in my
>> case, the tomcat-users.xml file:
>> http://www.jroller.com/gmazza/entry/ssl_for_web_services#SSL5 . The
>> validation appears to be the same validation done with SSL with basic
>> authentication, i.e., checking that the username and password exists within
>> the roles defined in the web.xml in the WAR hosting the web service.
>> Having
>> not yet debugged the Metro source code, I'm not sure whether Metro is
>> hardcoded to be able to handle only GlassFish and Tomcat or can generically
>> do container validation with any servlet container (I would suspect the
>> latter), or what it would do for OSGi environments for that matter.
>>
>> Is there a way to do this right now with CXF? CXF raises "General security
>> error (WSSecurityEngine: No password callback supplied)" if I don't provide
>> a server-side password callback handler as here:
>>
>> https://github.com/gmazza/blog-samples/blob/master/cxf_usernametoken_profile/war/src/main/webapp/WEB-INF/cxf-servlet.xml#L19
>> .
>> If not, I'm not sure if it's worth implementing--I guess it's a question of
>> how much additional benefit it would provide, the amount of effort it would
>> take to do so in a generic fashion, and risk of security vulnerabilities.
>>
>> Regards,
>> Glen
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Container-validation-of-UsernameToken-passwords-tp5719516.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>
>
>