See comments inline please. Regards, Werner
> -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 20. September 2006 10:31 > An: [email protected] > Cc: Dittmann, Werner > Betreff: Re: Principle question about the need of username an password > > Hello Werner, > > thanks a lot for your answer, which pushed me a big step ahead. > But I've got some questions left: > > >> I think that everything I need for the keystore is > >> defined in the "crypto.properties"-file - isn't it? > > > > No, it isn't. The crypto.properties file just defines the type of > > keystore to use, > > ACK. That's: > org.apache.ws.security.crypto.merlin.keystore.type=jks > > > > the provider, > > ACK. That's: > org.apache.ws.security.crypto.provider=org.apache.ws.security. > components.crypto.Merlin > > > > the password for the keystore. > > ACK. That's: > org.apache.ws.security.crypto.merlin.file=c:/java/keystore/cli > ent.keystore.jks > and > org.apache.ws.security.crypto.merlin.keystore.password=secret > > > But what about these: > org.apache.ws.security.crypto.merlin.keystore.alias=clientkey > org.apache.ws.security.crypto.merlin.alias.password=secret > These were used in ancient times - but no longer anymore. We need to delete them from the doc/examples :-) . > > Aren't these exactly the informations you write about: > > "To sign requests you need to identify the certificate inside > the keystore" > > !?? > > If I identify the certificate in the Callback-class and in > crypto.properties, > then in my opinion this is double-user/password-cumbersome!?? > > Besides: > You write about "certificate inside the keystore". Others > talk about "keys > inside the keystore". Is there a difference or are these just > synonyms? > As stated above: the "alias" related data in the crypto properties are not used anymore. The user (alias) is defined in the WSDD, the password via the callback - a configuration file should never contain a password, that's the main reason to have a callback. It's the callback's job to get and hide the password. An entry in the keystore usually consists of two elements: - a private key, encrypted and protected by a password (key inside keystore) - and a X.509 certificate that holds the associated public key. The certificate itself is usually signed by a certificate authority who has verfied that the public key belongs to the right person/owner. Then anybody can verify a signature using the public key and can identify the signer. For Signatures the client signs with its private key stored in its keystore, the server verifies the signature using the client's public key contained in the client's certificate. For encryption (client to server) WSS4J uses the public key of the server (stored in server's certificate) to encrypt the necessary data. The server uses it's private key to perform decryption. Thus look at a usual setup: ,''''''''''''''''''''''''''| ........................... | +----+ | | +----+ | | | CA | | | | CA | | | |root| | | |root| | | |cert| | | |cert| | | +-++-+ | | +-++-+ | | / \ | | / \ | | / \ | | / \ | | / \ | | / \ | | +---+--+ ++-----+ | | +---+--+ ++-----+ | | |Server| |Client| | | |Server| |Client| | | | cert | | cert | | | | cert | | cert | | | +------+ +--+---+ | | +--+---+ +------+ | | | | | | | | +---+---+ | | +--+----+ | | |Client | | | |Server | | | |private| | | |private| | | | key | | | | key | | | +-------+ | | +-------+ | `--------------------------' `-------------------------' Client's keystore Server's keystore (Client cert optional) This is a usual setup to sign/encrypt messages between client and server and server and client. You may even run without a root certificate if you trust the "self-signed" certificates of your clients. But usually it is a good idea to have a root certificate. You can run an own small certificate authority (e.g. using openSSL) if you want. But this would then require a good planning etc. > > > This was "client-side-confusion". But I've got some > "server-side-confusion" too: > > > > the "user" (usually the alias name of the certificate in the > > keystore) and you need the password to unlock the user's private key > > As far as I understand, every keystore-file has a > store-password and every > key _within_ the keystore-file has an alias > ((PWCallback-)user!?? - right?) and > it's own key-password ((PWCallback-)password!?? - right?). > > If I import a client-key into the server-keystore like: > %JAVA_HOME%\bin\keytool -import -alias clientkey -file > clientkey.export \ > -keystore server.keystore.jks -storepass secret > You never import the "client-key" into the server's keystore. At most you may import the client's certificate into the server's keystore to be able to verify the client's signature. Even that is not necessary because you my send the binary presentation of the client's certificate to the server with each request and the server cal validate that certificate using the root certificate of the cerificate authority. Of course, the server's keystore must contain this root certificate. Welcome to the world of PKI :-) . > Which key-password will the imported key have? The one it has in the > client-keystore (which it was exported from) too? In real > live the customer > (client) maybe wouldn't tell me about it... > > What if I import the client-key into the server-keystore with > a different > alias then it has in the client-keystore? Then the user used > in wss4j will > only match on one side of the communication!?? > > > I apologise for this annoying beginner-questions! > > Thanks again for bearing with me! > > Stephan > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
