0 Replies Latest reply on Nov 12, 2012 3:00 PM by okidoky

    WS-Trust STS callback provides expected password, but then global security domain checks it again, WHY?

    okidoky

      I have a working application that uses webservices using CXF with WS-Trust in JBoss 7.

      I have a client, sts, and server. Client wants to make web-service calls to server.

      Client provides CallbackHandler, which is called. When called with a WSPasswordCallback.identifier matching the user, I do a setPassword on it.

      CXF client code proceeds by contacting the STS.

      STS has a CallbackHandler as well. It is called, and when identifier matches the user name, I do a setPassword on it as well.

       

      So far so good.

       

      CXF (or JBoss) then insists on there being defined a security-domain in jboss-web.xml, or else it'll fail.

      I configure a security-domain in standalone.xml, and have it use user/role files.

      When I declare that user-name and password in it, and (I guess) when I provide a "friend" role (don't know if that's needed), then the whole thing clears and every works.

       

      The problem: I want the application to allow a user to configure a password at runtime, both on the server and client sides.

      The call-back handlers on both the client side and on the server side (in the sts), have the opportunity to query a database for the password.

       

      But the password is getting verified TWICE ! Once right after the sts callback, and then it insists on verifying that password a second time with the security-domain specified in standalone.xml.

       

      I don't want that second redundant authorization. Also, how the password is stored is highly proprietary. I don't want to have to write a global authenticaion security domain custom thingy of sorts.

      And why should I, the password is already cleared once! Why again, and outside the app? Can't I completely handle authentication inside the application level?