Hi Jake,

   I'd like to understand your scenario a little more. Clearly you want to
flow some sort of identity from B to A. Is this flow of identity because
a) you want to do authorization checks at A, instead of doing it a B. Since
A would trust B, B could just put in the username in some header for A.
b) security between B and A is important? If so, how are you going to secure
the message exchange? Resigning with the same username token at B would
defeat the purpose since really the UsernameToken is from A, and hence only
A can sign it
c) You could send a username/password in plain text to B (offcourse the
username would be encrypted by B's X509 public key), B does a LogonUser
against Active Directory by default, B the impersonates using that identity,
and then could use something like Kerberos to talk to A (this would involve
setting up delegation at the domain controller, and C, A and B would have to
be set up in a private domain)

   The problem with the trivial approach is that once B receives the
username token, it does not have access to the password, and hence cannot
just create a new username token to send to A. Let me know what your
scenario is and I'm sure i'll be able to address your concern a little
better

Thanks,

Sidd [MSFT]