Dittmann, Werner wrote: > Steve, > > well, at the level of the WSSecurityEngine we could add > the original exeption that causes the WSSecurityException. > > On the other hand, if you supply too much information > why a specific security check failed you may give a malicious > person who tries to attack your system additional info how to > proceed with the attack. Thus we decided to just say: > "no password for xyz". This does not give info if there is a > user "xyz" that has no password, or if there is a user "xyz" at > all. >
Yes, but that's why we are allowed to beat developers senseless who supply to much information in their error responses. Helps to keep morale up too. Actually we tossed the same thing around when first coming up with using a SOAP interface for authentication and authorization for a new desktop application we are launching with how much information to respond with if someone is sniffing the packets. Although when the username/password is sent it is over SSL so it's a tad more tricky. We've got wss4j sitting on top handling the Authentication piece and then the Authorization is handled through a normal SOAP service. Since there will be no CSR that a user can talk to for problems the desktop application was just looking for a way to communicate to the user that either they haven't registered yet and need to do that through a web interface storefront or that the password is invalid. It's what happens with bizdev people think to much. We'll just roll with what is there now and if it becomes an issue I can always work on adding a HTTP Header to the response that the client can parse to get information or error codes from. Thanks. -- Steve Brunton <[EMAIL PROTECTED]> Phone: 404-885-2436 Chief Engineer AOL IM : schitzo42 CNN Internet Technologies ICBM: 84W 23' 45" 33N 45' 29" <*> Veni, vidi, Velcro -- I came, I saw, I stuck with it. <*>
