AW: [WSS4J] Suggested patch to promote more flexible sign/encrypt usage cases

Jon,

there may be one thing to check: the code sets up
the security header before it performs any signature
operations. Thus this could lead to an "empty"
security header in terms of ds:Reference. I'm not
sure how the verfication engine deals with that.=20
Could be a good idea to always specify "Token" so=20
that at least the security token is signed and the
Signature structure is not empty. Also the
receiving Axis handler performs a check if all
expected security operations were done. It
checks if the number of security ops, the type
and ordering of security ops match the=20
configured operations (in *.wsdd file)
Thus an empty Signature could lead to problems.=20

The idea behind to throw an exception: security=20
is a quite sensitive thing. Thus, if somebody specifies
an element to sign and this element is not in the
request message - it should fail. An idea would
be to introduce a parameter that defines=20
"how serious" to take it (yet another config option,=20
we will get "the most config data available" award for
Axis handlers sometimes :-) ).

Could be something like that:

Element body =3D (Element) WSSecurityUtil.findElement(envelope, =
elemName, nmSpace);
if (body =3D=3D null && takeItSerious =3D=3D verySerious) {
  throw new WSSecurityException(
	WSSecurityException.FAILURE,
	"noEncElement",
	new Object[] { nmSpace, elemName });
}
else {
  transforms =3D new Transforms(doc);
  =
transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS);
  sig.addDocument("#" + setWsuId(body), transforms);
}

Have this parameter configurable via *.wsdd file and it is up
to the deployer.

A similar thing could be done for Encryption. However, here
some more checks may be necessary. Or at least, similar to the
above, define that at least the body is always encrypted. Thus
we avoid the "empty" encryption structure. Other elements could
be optional because encryption works for "1 thru n" elements.

Regards,
Werner

> -----Urspr=FCngliche Nachricht-----
> Von: wss4j-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org=20
> [mailto:wss4j-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] Im Auftrag=20
> von Anderson Jonathan
> Gesendet: Donnerstag, 5. Februar 2004 00:03
> An: WSS4J
> Betreff: [WSS4J] Suggested patch to promote more flexible=20
> sign/encrypt usage cases
>=20
>=20
> Hey guys,
> 	WSSignEnvelope, line 257.  Looks as if it attempts to=20
> find the element
> specified to either be signed or encrypted, and throws an=20
> Exception if it
> cannot find it.  We've got a portal app that consumes a variety of =
web
> services, and the header information is not uniform across=20
> all of the SOAP
> messages sent.  Looking for a manner in which I could use=20
> WSS4J in a "if
> these elements are present, sign them" scenario I made the=20
> following *hack*:
>=20
> if (body =3D=3D null) {
>     /*
>     throw new WSSecurityException(
>         WSSecurityException.FAILURE,
>         "noEncElement",
>         new Object[] { nmSpace, elemName });
>     */
> }
> else
> {
>     transforms =3D new Transforms(doc);
>    =20
> =
transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS);
>     sig.addDocument("#" + setWsuId(body), transforms);
> }
>=20
> It works just great for signing, though I admit I have not a)=20
> verified the
> signatures yet (still testing) or b) tried this with=20
> encryption.  I now
> specify multiple elements to sign in the WSDoAllSender signatureParts
> parameter, and the handler will sign the elements if they are =
present.
>=20
> Thoughts anyone?  Am I digging myself into a hole here, or is=20
> this a valid
> use case for WSS4J?  Any ideas on what else would need to be=20
> modified to
> fully support this approach?
>=20
> Any and all feedback would be appreciated.
>=20
> 	Thanks,
> 	-Jon
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> wss4j-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wss4j-devel
>=20


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn