Announcement Announcement Module
Collapse
No announcement yet.
Communications management with PasswordDigest (WSPasswordCallback from WSS4J) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Communications management with PasswordDigest (WSPasswordCallback from WSS4J)

    Scenario:

    We are developing a Java library to deploy an authentication subsystem, which acts as an intermediary of two end-points: an originator program (which sends us the SOAP message, made by the client, as a CallbackHandler implementation) and a WebService (based on CXF, which will validate de user&password given).

    Here it is a logical diagram of the system:

    Code:
    |------|            |-------|            
    |Client|--SOAP msg->|Program|
    |------|            |-------|            
                          |           |--------|  
                          \-Callback->|Java Lib|
                                      |--------|                             
                                        |             |--|                |----|
                                        \-User&Pass-->|WS|<-(validation)->|LDAP|
                                                      |--|   SOAP msg     |----|
    As a is seen in other other implementations the code (to be added in our Java Lib) should be the next (taking into account that the type of the password, for -obviously- security reasons, is "PasswordDigest" (seen in the OASIS UserName Token specification, lines 196-197)):

    Code:
            if (callbacks[i] instanceof WSPasswordCallback) {
                WSPasswordCallback pc = (WSPasswordCallback) callbacks[i];
                sString login = pc.getIdentifier();
                String password = getPassword(login);
                pc.setPassword(password); 
            }
    The line
    Code:
    "String password = getPassword(login);"
    requires the local storage of a file (or a DB) in order to the user&pass maintenance and its subsequent check-up.

    So, and that is the obstacle, we are NOT allowed to maintain that file. In addition, the WebService only provides an authentication service (yes/no to an user and password given) and we don't have any other access to the originator Program or to the client.

    Any idea of how we should proceed?

    Thanks in advance.
Working...
X