Re: [axis2] design issues on client authentication

[Reshef Roy <ro...@yahoo.com>]

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

--- studium-sbr@web.de 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: axis-user@ws.apache.org
> > Gesendet: 02.06.06 09:55:47
> > An: axis-user@ws.apache.org
> > 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, studium-sbr@web.de <st...@web.de>
> 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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org