axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reshef Roy <roy_res...@yahoo.com>
Subject Re: [axis2] design issues on client authentication
Date Fri, 02 Jun 2006 18:30:27 GMT

Sorry Bille but I don't really understand what you are
looking for...

The database connection works for all Intranet
application, they can in principle all access the
database.

If you are talking about extranet or internet clients,
then if you want your service to to be "called from
everywhere" how do you want to secure it? You can
always give your clients some "secret" (whatever that
is, password of certificate or whatever), but if you
cannot trust them not to share that secret with others
then you can never be sure that you get a message from
them.
If you can trust them to that extent then you should
exchange certificates (like the security sample of
Axis2 1.0) - let them sign the message to your service
with THEIR private key and encrypt it with YOUR public
key (certificate). You will sign the outgoing message
with YOUR private key and encrypt it with THEIR public
key. But a minimum trust relationship is always
required. Security is not a matter of magic...

HTH,

/ Roy

--- studium-sbr@web.de wrote:

> Thanks Roy for your thoughts,
> 
> in my opinion your solution is of course better than
> clear passwords.
> The thing I don't like about it is the DB-connection
> which is required for all the client-applications.
> This takes away the smooth thing about the service
> being "called from everywhere".
> 
> The problem is I don't have a better idea ;)
> 
> Any other hints are appreciated
> 
> Bille
> 
> > -----Urspr�ngliche Nachricht-----
> > Von: Reshef Roy <roy_reshef@yahoo.com>
> > Gesendet: 02.06.06 15:32:47
> > An:   wss4j-dev@ws.apache.org
> > Betreff: Re: [axis2] design issues on client
> authentication
> 
> 
> > 
> > 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
> <studium-sbr@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
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


Mime
View raw message