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

All,

better coding:

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

Avoids NPE.

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 Dittmann Werner
> Gesendet: Donnerstag, 5. Februar 2004 08:13
> An: 'Anderson Jonathan'; WSS4J
> Betreff: AW: [WSS4J] Suggested patch to promote more flexible=20
> sign/encrypt usage cases
>=20
>=20
> Jon,
>=20
> 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
>=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 :-) ).
>=20
> Could be something like that:
>=20
> Element body =3D (Element) WSSecurityUtil.findElement(envelope,=20
> 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);
>  =20
> =
transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS);
>   sig.addDocument("#" + setWsuId(body), transforms);
> }
>=20
> Have this parameter configurable via *.wsdd file and it is up
> to the deployer.
>=20
> 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.
>=20
> Regards,
> Werner
>=20
> > -----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=20
> 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
> >=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=20
> signatureParts
> > parameter, and the handler will sign the elements if they=20
> 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
>=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