Hi Bille, Ruchith. I was facing more or less the same issue. I have a Webservice and a client application which should access it securely. I am using rampart and WSS4J, and am using a *keystore* in a similar way to that of the security sample of Axis2 1.0. One thing troubled me though - the keystore is stored in the client secUtil.jar, and if this JAR file becomes available to unwanted parties (JARs seem to be prone to become too broadly available as people view these as executables...) then they can open the keystore easily (as its password is stored in a property file in the JAR itself) and retrieve the keys/certificates from there (as the password of the users is either hard-coded in a Java class or read from a property file). If there is one thing I don't like it's cleartext passwords in property files or in the code (which can easily be decompiled...).
I have solved it this way: - In my database (which is available to both the client application and the webservice code) I have created an "account" table which has as columns a username and a "cleartext" password. There are 3 rows in this table, for users "service", "client" and "keystore". - I have implemented a PasswordStore class which access this table (using hibernate), and then encrypts the cleartext password using the standard JCrypt.java implementation (and a salt string which is hidden somewhere... secret :). - I have implemented a crypto.provider class which inherits from WSS4J Merlin. The only difference is that this class reads the keystore password not from a preperty file but using the PasswordStore (so using the "keystore" account in the database). - Also the PasswordCallback uses this PasswordStore implementation for the passwords of the client and service users. - of course, the keystores (for both the client and service) were created using the encrypted passwords. So this way, even if my security JAR becomes available to unwanted parties, there is nothing they can do because they still need the passwords. And if on the other hand they get access to the database so the cleartext passwords are compromised, they still need both the keystore AND the salt for the password encryption. It is maybe a slightly paranoidic solution, but it works... Ruchith, Werner - I would be happy to hear your idea about it. If required, I can provide the code mentioned above. Nice weekend all, / Roy --- [EMAIL PROTECTED] wrote: > Hi Ruchith, > > thanks for your advice. > I read about rampart (WSS4j) but didn't get in too > deep. > Using plain text password isn't suitable for my > goals. As I said, this password could be directly > accessed by other parties, who should definitely not > use my service. > I thought about using a combination of a password an > the hashed URL of the Client as a > password-mechanism. But this solution doesn't > satisfy me either. > Do you have any details for the password digest and > the callback solution; it didn't get really clear to > me. > > Any further ideas and / or links are highly > appreciated > > Thanks a lot > > Bille > > > -----Urspr�ngliche Nachricht----- > > Von: [email protected] > > Gesendet: 02.06.06 09:55:47 > > An: [email protected] > > Betreff: Re: [axis2] design issues on client > authentication > > > > Hi Bille, > > > > How about using "rampart" module to enable > UsernameToken > > authentication on that particular service. This > will force all your > > clients to send requests with a UsernameToken. > > > > With this approach you can limit your > configurations to the service > > only. If you use a plain text password with the > service then you can > > carryout the authentication at the service impl > itself. Or else if you > > use the "PasswordDigest" mechanism you can handle > handle multiple user > > auth in the PasswordCallbackHandler that you > specify in the > > configuration. > > > > If you are interested in this option and if this > you want more > > clarifications , I can provide you a further > explanations. > > > > Thanks, > > Ruchith > > > > On 6/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > > Hello to the list, > > > > > > I'm interested how you would deal such a > scenario: > > > I have a web service which is meant to run in an > Intranet-Environment in our company. There will be > different Intranet-Websites and other applications > which will use the service. > > > My aim is to limit the use of the service to > special clients; say application A and D and WebSite > X. How can I achieve this without using some hard > coded keys which I register at the service. > > > I'm against those keys because some code is > accessable through a Content Management System, so > it would be easy to "copy" the keys und use it in > some "not registered" application. > > > > > > I hope I put it somehow clearly into words. > Thanks in adavance for any hints and comments > > > > > > Bille > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
