tag:blogger.com,1999:blog-7391783704166348052.post8869747415400995065..comments2024-03-15T22:26:58.542-07:00Comments on Open Source Security: Apache CXF STS documentation - part IXColm O hEigeartaighhttp://www.blogger.com/profile/10711987281965801793noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-7391783704166348052.post-17227317931633226732013-04-04T02:22:28.862-07:002013-04-04T02:22:28.862-07:00
Please take these questions to the CXF user list ...<br />Please take these questions to the CXF user list instead.<br /><br />Colm.Colm O hEigeartaighhttps://www.blogger.com/profile/10711987281965801793noreply@blogger.comtag:blogger.com,1999:blog-7391783704166348052.post-3775790030615187552013-04-03T12:34:54.507-07:002013-04-03T12:34:54.507-07:00To add to this. I don't even see where the org...To add to this. I don't even see where the org.apache.cxf.sts.token.validator.UsernameTokenValidator is ever used. In fact, in the debugger it looks like the only validator ever called when submitting an RST with a username token is org.apache.ws.security.validate.UsernameTokenValidtor. This despite the fact that I am using the CXF DefaultSecurityTokenProvider.<br /><br />I am truly confused.Reaperhttps://www.blogger.com/profile/09230258417939058697noreply@blogger.comtag:blogger.com,1999:blog-7391783704166348052.post-46683722856632686302013-04-03T11:59:09.683-07:002013-04-03T11:59:09.683-07:00Unfortunately, this does not work as expected. I&#...Unfortunately, this does not work as expected. I've created a new DefaultSecurityTokenProvider class that is identical to the one provided by CXF except that when I create the UsernameTokenValidtor I set the validator to a custom implementation. However, it seems like it still uses the default validator.<br /><br />Am I going about this the wrong way?Reaperhttps://www.blogger.com/profile/09230258417939058697noreply@blogger.comtag:blogger.com,1999:blog-7391783704166348052.post-28187548349701000042013-04-02T08:52:03.555-07:002013-04-02T08:52:03.555-07:00
Correct. The DefaultSecurityTokenServiceProvider ...<br />Correct. The DefaultSecurityTokenServiceProvider is just an easy way to set up the STS for most use-cases. You can just create an STS using the more configurable way.<br /><br />Colm.Colm O hEigeartaighhttps://www.blogger.com/profile/10711987281965801793noreply@blogger.comtag:blogger.com,1999:blog-7391783704166348052.post-15190805201905234752013-04-02T08:09:59.385-07:002013-04-02T08:09:59.385-07:00I see that. But am I right in assuming that I coul...I see that. But am I right in assuming that I could not reuse the DefaultSecurityTokenServiceProvider if I wanted to call my own validator?<br /><br />It looks like I would have to create my own version of DefaultSecurityTokenServiceProvider that sets the custom validator in the populateAbstractOperation() method.Reaperhttps://www.blogger.com/profile/09230258417939058697noreply@blogger.comtag:blogger.com,1999:blog-7391783704166348052.post-82748535328940297402013-04-02T05:51:50.996-07:002013-04-02T05:51:50.996-07:00Yes, you can inject your custom WSS4J Validator im...<br />Yes, you can inject your custom WSS4J Validator implementation into the STS's UsernameTokenValidator via the "setValidator" method. See here:<br /><br />http://svn.apache.org/viewvc/cxf/trunk/services/sts/sts-core/src/main/java/org/apache/cxf/sts/token/validator/UsernameTokenValidator.java?view=markup<br /><br />Colm.Colm O hEigeartaighhttps://www.blogger.com/profile/10711987281965801793noreply@blogger.comtag:blogger.com,1999:blog-7391783704166348052.post-27389228933693056272013-04-01T10:25:42.577-07:002013-04-01T10:25:42.577-07:00Hi Colm,
Is there a way to configure the CXF/Tale...Hi Colm,<br /><br />Is there a way to configure the CXF/Talend STS to use a custom UsernameTokenValidator?<br /><br />The reason I ask is that I would like to call an external identity store to validate the username/password. The identity store has an interface which accepts a username and password and returns true of false depending on whether the password is correct or not.<br /><br />So far the only way I know to affect the behavior of the UsernameTokenValidtor is to specify a callback handler. Unfortunately, the default UsernameTokenValidator does not explicitly pass the password received from the username token to the callback handler and the identity store I am trying to work with will not return the password associated with the id (it only validates a username/password pair).<br /><br />While I can create a solution using the username callback handler but it is not very pretty. The solution takes advantage of the fact that while the default UsernameTokenValidator does not explicitly pass the password in the username token, it does pass the entire contents of the soap message as part of the "data" property. From that data, I can extract the SOAP message, then the WSSecurity header, then the username token, and finally the password.<br /><br />What I don't like about this solution is that the process of extracting the username and password is already performed by the code that calls the callback handler. I'm doing it a second time in the callback handler which seems wasteful.<br /><br />Thus, I'm wondering if I can create my own UsernameTokenValidtor and overrride the one that the CXF STS uses by default.Reaperhttps://www.blogger.com/profile/09230258417939058697noreply@blogger.com