You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Christof Soehngen <Ch...@SYRACOM.DE> on 2004/05/12 10:27:34 UTC
Integration of WSS4J into a existing project
Hello there,
my customer wants to integrate WS-Security into an existing project build on Axis (the project offers some additional header like compression ...). The benefit of using WSS4J is obvious.
The way I understood the architecture of WSS4J is that one can (and should) implement its own custom handlers that uses the WSS4J framework (WSSignEnvelope, WSEncryptBody, WSSecurityEngine, ..., almost everything that isn't a handler ;-).
Concerning encryption and signature, everything works fine, but we plan on adding some additional information to the security header (according to the spec, there is room for those enhancements). The enhancements we need (and that are - at the moment - not in the scope of WSS4J) are:
* Timestamp with one or two additional info (for example, when the client regards the whole message as "lost", not just when the security header expires).
* UsernameToken with some additional info (additional IDs and something like that)
* Certificate Path should be checked (the certificate that was used for signing the message is sent with the message, the check is wether a connection to existing certificates in the keystore can be made)
We want to design the handlers as loosely coupled to WSS4J as possible, so that we can replace the whole jar when new versions come out. Unfortunately, at the moment it is not possible just to write custom handlers to implement the enhancements mentioned above.
My suggestions are the following:
* Timestamp and UsernameToken: Move the validation from security engine to the receiving handler, so that one can use it's own validation mechanisms or none if desired (callback for password isn't enough, we want to hand over the token to the service itself). Furthermore, additional elements from Timestamp or UsernameToken should be included in the WSSecurityEngineResult
* As an alternative, the validation could be made disengageable, so the sending handler could add a custom UsernameToken and Timestamp that is ignored by WSSecurityEngine but handled by the new custom receiving handler.
* There is another possibility: Create a whole new token for the custom user information that is created by the custom handler but encrypted and signed by WSS4J (and vice versa for decryption on receiver side). Would this be the better, cleaner option? But I still see the problem with the timestamp checking in WSSecurityEnginge, this seems not to be flexible enough?
* CertificatePath: Crypto needs a method to search for a certificate based on the DN. This way, one can retrieve the certicate chain of the issuer of the certificate, used to sign the transmitted message, from the keystore, if it exists. CertPathAPI can then be used to validate the whole bunch of certs.
If some of this ideas seem acceptable for you, I would gladly try to implement them. Any suggestions are most welcome.
Regards,
Christof
RE: Integration of WSS4J into a existing project
Posted by Anne Thomas Manes <an...@manes.net>.
One caveat, though.
Dims -- didn't you say that WSS4J requires Axis 1.2?
-----Original Message-----
From: Davanum Srinivas [mailto:davanum@gmail.com]
Sent: Wednesday, May 12, 2004 5:15 AM
To: Christof Soehngen
Cc: fx-dev@ws.apache.org
Subject: Re: Integration of WSS4J into a existing project
Christof,
Everything is fair game. Go for it. Werner and I will review patches
and comment if necessary. Having said that, please don't submit 1 BIG
patch. Small, incremental patches are better to handle and digest :)
thanks,
dims
----- Original Message -----
From: Christof Soehngen <ch...@syracom.de>
Date: Wed, 12 May 2004 10:27:34 +0200
Subject: Integration of WSS4J into a existing project
To: fx-dev@ws.apache.org
Hello there,
my customer wants to integrate WS-Security into an existing project
build on Axis (the project offers some additional header like compression
...).
The benefit of using WSS4J is obvious.
The way I understood the architecture of WSS4J is that one can (and should)
implement its own custom handlers that uses the WSS4J framework
(WSSignEnvelope,
WSEncryptBody, WSSecurityEngine, ..., almost everything that isn't a handler
;-).
Concerning encryption and signature, everything works fine, but we plan on
adding some additional information to the security header (according to the
spec, there is room for those enhancements). The enhancements we need (and
that
are - at the moment - not in the scope of WSS4J) are:
Timestamp with one or two additional info (for example, when the
client regards the whole message as "lost", not just when the security
header
expires).
UsernameToken with some additional info (additional IDs and something like
that)
Certificate Path should be checked (the certificate that was used for
signing the message is sent with the message, the check is wether a
connection
to existing certificates in the keystore can be made)
We want to design the handlers as loosely coupled to WSS4J as possible, so
that we can replace the whole jar when new versions come out. Unfortunately,
at
the moment it is not possible just to write custom handlers to implement the
enhancements mentioned above.
My suggestions are the following:
Timestamp and UsernameToken: Move the validation from security engine to
the receiving handler, so that one can use it's own validation mechanisms
or
none if desired (callback for password isn't enough, we want to hand over
the
token to the service itself). Furthermore, additional elements from
Timestamp
or UsernameToken should be included in the WSSecurityEngineResult
As an alternative, the validation could be made disengageable, so the
sending handler could add a custom UsernameToken and Timestamp that
is ignored
by WSSecurityEngine but handled by the new custom receiving handler.
There is another possibility: Create a whole new token for the custom user
information that is created by the custom handler but encrypted and
signed by WSS4J (and vice versa for decryption on receiver side). Would
this
be the better, cleaner option? But I still see the problem with the
timestamp
checking in WSSecurityEnginge, this seems not to be flexible enough?
CertificatePath: Crypto needs a method to search for a certificate based
on the DN. This way, one can retrieve the certicate chain of the issuer
of the certificate, used to sign the transmitted message, from the
keystore,
if it exists. CertPathAPI can then be used to validate the whole bunch of
certs.
If some of this ideas seem acceptable for you, I would gladly try to
implement them. Any suggestions are most welcome.
Regards,
Christof
Re: Integration of WSS4J into a existing project
Posted by Davanum Srinivas <da...@gmail.com>.
Christof,
Everything is fair game. Go for it. Werner and I will review patches
and comment if necessary. Having said that, please don't submit 1 BIG
patch. Small, incremental patches are better to handle and digest :)
thanks,
dims
----- Original Message -----
From: Christof Soehngen <ch...@syracom.de>
Date: Wed, 12 May 2004 10:27:34 +0200
Subject: Integration of WSS4J into a existing project
To: fx-dev@ws.apache.org
Hello there,
my customer wants to integrate WS-Security into an existing project
build on Axis (the project offers some additional header like compression ...).
The benefit of using WSS4J is obvious.
The way I understood the architecture of WSS4J is that one can (and should)
implement its own custom handlers that uses the WSS4J framework
(WSSignEnvelope,
WSEncryptBody, WSSecurityEngine, ..., almost everything that isn't a handler
;-).
Concerning encryption and signature, everything works fine, but we plan on
adding some additional information to the security header (according to the
spec, there is room for those enhancements). The enhancements we need (and that
are - at the moment - not in the scope of WSS4J) are:
Timestamp with one or two additional info (for example, when the
client regards the whole message as "lost", not just when the security header
expires).
UsernameToken with some additional info (additional IDs and something like
that)
Certificate Path should be checked (the certificate that was used for
signing the message is sent with the message, the check is wether a
connection
to existing certificates in the keystore can be made)
We want to design the handlers as loosely coupled to WSS4J as possible, so
that we can replace the whole jar when new versions come out. Unfortunately, at
the moment it is not possible just to write custom handlers to implement the
enhancements mentioned above.
My suggestions are the following:
Timestamp and UsernameToken: Move the validation from security engine to
the receiving handler, so that one can use it's own validation mechanisms or
none if desired (callback for password isn't enough, we want to hand over the
token to the service itself). Furthermore, additional elements from Timestamp
or UsernameToken should be included in the WSSecurityEngineResult
As an alternative, the validation could be made disengageable, so the
sending handler could add a custom UsernameToken and Timestamp that
is ignored
by WSSecurityEngine but handled by the new custom receiving handler.
There is another possibility: Create a whole new token for the custom user
information that is created by the custom handler but encrypted and
signed by WSS4J (and vice versa for decryption on receiver side). Would this
be the better, cleaner option? But I still see the problem with the timestamp
checking in WSSecurityEnginge, this seems not to be flexible enough?
CertificatePath: Crypto needs a method to search for a certificate based
on the DN. This way, one can retrieve the certicate chain of the issuer
of the certificate, used to sign the transmitted message, from the keystore,
if it exists. CertPathAPI can then be used to validate the whole bunch of
certs.
If some of this ideas seem acceptable for you, I would gladly try to
implement them. Any suggestions are most welcome.
Regards,
Christof