You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Bob Coss (JIRA)" <ji...@apache.org> on 2006/08/29 16:37:22 UTC
[jira] Created: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
UsernameTokenProcessor not processing unhashed UsernameToken
------------------------------------------------------------
Key: WSS-54
URL: http://issues.apache.org/jira/browse/WSS-54
Project: WSS4J
Issue Type: Bug
Reporter: Bob Coss
Assigned To: Davanum Srinivas
The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas updated WSS-54:
--------------------------------
Assignee: (was: Davanum Srinivas)
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: https://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12431268 ]
Ruchith Udayanga Fernando commented on WSS-54:
----------------------------------------------
Actually the callback handler is called in the case when the password is not a hashed password.
In this case the both username and password values from the UsernameToken element are set in the WSPasswordCallback instance sent into the callback handler. Usage flag of the WSPasswordCallback is set to WSPasswordCallback.USERNAME_TOKEN_UNKNOWN. One can carryout authentication of the user at the callback with this information within the callback handler. See line : 123-136 of UsernameTokenProcessor[1] (svn revision - 438091 - right now).
A simple example of a callback handler implementation can be found here [2]
[1] https://svn.apache.org/repos/asf/webservices/wss4j/trunk/src/org/apache/ws/security/processor/UsernameTokenProcessor.java
[2] https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/security/sc/PWCallback.java
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Bob Coss (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12442209 ]
Bob Coss commented on WSS-54:
-----------------------------
[[ Old comment, sent by email on Tue, 29 Aug 2006 10:28:05 -0500 ]]
That doesn't seem to make sense to me the way this is handled.
According to the way the callback is being processed, the only thing
that can be thrown is a UnsupportedCallbackException() or IOException.
In UsernameTokenProcessor, it will throw:
throw new WSSecurityException(WSSecurityException.FAILURE,
"noPassword", new Object[]{user});
and not a
WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
In the spirit of JAAS, shouldn't the handler be providing the value of
the password to the callback, and the UsernameTokoenProcessor evaluating
the password supplied in the token with the one from application?
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated WSS-54:
-----------------------------------
Attachment: wss4j_wss54.patch
Please see the attached patch for a solution to this problem. The patch contains four things:
1) More extensive testing of processing Username Tokens.
2) Standard FAILED_AUTHENTICATION error codes are now returned, as suggested by Evan. In this way, no information is leaked to a potential attacker.
3) The UsernameTokenProcessor now does the authentication for both plaintext and password digest types. In both these cases, the sole function of the callback is to supply the password. This is more consistent than the existing solution.
4) By default custom password types are rejected. However, a configuration variable is added to WSSConfig and WSHandlerConstants, which enables the UsernameTokenProcessor to handle custom password types. In this case, all authentication is delegated to the callback handler. The reason they are rejected by default is to avoid a potential security hole when the implementing callback handler code leaves out a test for USERNAME_TOKEN_UNKNOWN.
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: https://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Attachments: wss4j_wss54.patch
>
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Ever A. Olano (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12459510 ]
Ever A. Olano commented on WSS-54:
----------------------------------
I just reread the last paragraph that I wrote and feel that I need to clarify it. I think, what I wish to happen is that everywhere it throws FAILURE with "noPassword" as the resource, it should instead throw FAILED_AUTHENTICATION. i.e. same error message for "non-existent username/password" and "invalid password".
Hope that's clearer. :)
Thanks again,
Ever
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Ever A. Olano (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12459510 ]
Ever A. Olano commented on WSS-54:
----------------------------------
I just reread the last paragraph that I wrote and feel that I need to clarify it. I think, what I wish to happen is that everywhere it throws FAILURE with "noPassword" as the resource, it should instead throw FAILED_AUTHENTICATION. i.e. same error message for "non-existent username/password" and "invalid password".
Hope that's clearer. :)
Thanks again,
Ever
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Ever A. Olano (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12459509 ]
Ever A. Olano commented on WSS-54:
----------------------------------
I think I can live with the callback handler determining from the usage (USERNAME_TOKEN or USERNAME_TOKEN_UNKNOWN) whether or not to do the validation itself. However, In UsernameTokenProcessor.java:
} else if (cb != null) {
WSPasswordCallback pwCb = new WSPasswordCallback(user, password,
pwType, WSPasswordCallback.USERNAME_TOKEN_UNKNOWN);
callbacks[0] = pwCb;
try {
cb.handle(callbacks);
} catch (IOException e) {
throw new WSSecurityException(WSSecurityException.FAILURE,
"noPassword", new Object[]{user});
} catch (UnsupportedCallbackException e) {
throw new WSSecurityException(WSSecurityException.FAILURE,
"noPassword", new Object[]{user});
}
}
It should throw FAILED_AUTHENTICATION instead of FAILURE. Either that or have another exception, say, FailedAuthenticationException that cb.handle() may throw so that this code can differentiate between a real "noPassword" scenario or a failed authentication.
By the way, this is probably being nitpicky, but we should probably get rid of the "noPassword" resource and return the same error message for failed authentication instead. That way, a hacker would not be able to tell whether or not the username they tried to authenticate with exists.
Thanks,
Ever
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Resolved: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin resolved WSS-54.
----------------------------
Resolution: Fixed
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: https://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Attachments: wss4j_wss54_revised.patch
>
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fred Dushin updated WSS-54:
---------------------------
Fix Version/s: 1.5.4
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: https://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Fix For: 1.5.4
>
> Attachments: wss4j_wss54_revised.patch
>
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Ever A. Olano (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12459509 ]
Ever A. Olano commented on WSS-54:
----------------------------------
I think I can live with the callback handler determining from the usage (USERNAME_TOKEN or USERNAME_TOKEN_UNKNOWN) whether or not to do the validation itself. However, In UsernameTokenProcessor.java:
} else if (cb != null) {
WSPasswordCallback pwCb = new WSPasswordCallback(user, password,
pwType, WSPasswordCallback.USERNAME_TOKEN_UNKNOWN);
callbacks[0] = pwCb;
try {
cb.handle(callbacks);
} catch (IOException e) {
throw new WSSecurityException(WSSecurityException.FAILURE,
"noPassword", new Object[]{user});
} catch (UnsupportedCallbackException e) {
throw new WSSecurityException(WSSecurityException.FAILURE,
"noPassword", new Object[]{user});
}
}
It should throw FAILED_AUTHENTICATION instead of FAILURE. Either that or have another exception, say, FailedAuthenticationException that cb.handle() may throw so that this code can differentiate between a real "noPassword" scenario or a failed authentication.
By the way, this is probably being nitpicky, but we should probably get rid of the "noPassword" resource and return the same error message for failed authentication instead. That way, a hacker would not be able to tell whether or not the username they tried to authenticate with exists.
Thanks,
Ever
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12431268 ]
Ruchith Udayanga Fernando commented on WSS-54:
----------------------------------------------
Actually the callback handler is called in the case when the password is not a hashed password.
In this case the both username and password values from the UsernameToken element are set in the WSPasswordCallback instance sent into the callback handler. Usage flag of the WSPasswordCallback is set to WSPasswordCallback.USERNAME_TOKEN_UNKNOWN. One can carryout authentication of the user at the callback with this information within the callback handler. See line : 123-136 of UsernameTokenProcessor[1] (svn revision - 438091 - right now).
A simple example of a callback handler implementation can be found here [2]
[1] https://svn.apache.org/repos/asf/webservices/wss4j/trunk/src/org/apache/ws/security/processor/UsernameTokenProcessor.java
[2] https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/security/sc/PWCallback.java
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated WSS-54:
-----------------------------------
Attachment: wss4j_wss54_revised.patch
Here is a revised patch for this issue. This patch preserves the original functionality whereby the authentication of plaintext password or unknown password types is delegated to the callback handler. We really need to revisit this architecture for 2.0, as the callback handler architecture is not being used correctly.
This patch contains three things:
1) More extensive testing of processing Username Tokens.
2) Standard FAILED_AUTHENTICATION error codes are now returned, as suggested by Evan. In this way, no information is leaked to a potential attacker.
3) By default custom password types are rejected. However, a configuration variable is added to WSSConfig and WSHandlerConstants, which enables the UsernameTokenProcessor to handle custom password types. In this case, all authentication is delegated to the callback handler.
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: https://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Attachments: wss4j_wss54_revised.patch
>
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Bob Coss (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12442209 ]
Bob Coss commented on WSS-54:
-----------------------------
[[ Old comment, sent by email on Tue, 29 Aug 2006 10:28:05 -0500 ]]
That doesn't seem to make sense to me the way this is handled.
According to the way the callback is being processed, the only thing
that can be thrown is a UnsupportedCallbackException() or IOException.
In UsernameTokenProcessor, it will throw:
throw new WSSecurityException(WSSecurityException.FAILURE,
"noPassword", new Object[]{user});
and not a
WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
In the spirit of JAAS, shouldn't the handler be providing the value of
the password to the callback, and the UsernameTokoenProcessor evaluating
the password supplied in the token with the one from application?
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated WSS-54:
-----------------------------------
Attachment: (was: wss4j_wss54.patch)
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: https://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-54) UsernameTokenProcessor not processing
unhashed UsernameToken
Posted by "Fred Dushin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590098#action_12590098 ]
Fred Dushin commented on WSS-54:
--------------------------------
Applied Colm's patch, which has been reviewed on the list.
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: https://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Attachments: wss4j_wss54_revised.patch
>
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken that was hashed with a nonce and timestamp. Anything else that is passed to it will create a valid principal regardless of what the implementations password callback handler does. This is creating confusion and preventing WSS4J from being used for anything where the the UsernameToken is passed plainly. It is understood that doing this in a production environment is discouraged, but it is usefull to have this implementation work as expected so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not of hashed, nothing is done with the WSPasswordCallback object after the call to the password handler handle method is invoked. Since nothing is done with it, the code drops through and sets up a valid principal with the userid and returns. There is no way to signal a WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org