OpenSAML user discussion

[Brent Putman <>]

Mike Klein wrote:
> java-xmltooling 334
> java-openws 64
> java-opensaml2 927
>
> Seemed to be the best I could to and get green on build. xmltool tests
> passed, single failure in openws test and opensaml2 had numerous test
> issues.
>
>   

They are mostly building now.  Looks like there is still a problem with
compiling one class in java-opensaml2, which I believe Chad is working
on.  I imagine that will be fixed pretty quick.


> I still seem to be missing build with SignatureValidator? class. My
> urgency is for build which supports just marshalling and signing. Enc
> less important at this point.
>   

All the trust engine stuff, of which the signature validation is one
type, is in flux and being rewritten.  Not sure where that stands.

> Can I get another estimate on some sort of 'good' version, perhaps where
> tests pass green too...or is this too much to ask for still?
>
> I think you're code may be somewhat IBM jre non-friendly...all the
> aes/aeswrap stuff isn't in ibm jre.
>   

AFAIK, the IBM JRE supports AES as a block cipher for data encryption
just fine.  However, last I checked (about 2 1/2 months ago), the IBM
security provider that they ship with their JRE did not support the AES
as a key wrap method (JCA specifier "AESwrap").  The 128-bit and 256-bit
variants are mandatory for the XML Encryption spec.  So the situation is
really the reverse - IBM's default JRE security provider stack doesn't
currently support XML Encryption.  But that's perhaps not terribly
significant, I'd guess not many people use symmetric key wrap, as
opposed to asymmetric key transports (which I believe work fine with
IBM's default provider stack).

However, more significantly, IBM's security provider stack does not
(rather, did not as of 2 1/2 months ago) support the "ISO10126Padding"
padding scheme, which is also mandatory for the XML Encryption spec -
it's the padding scheme used for all data encryption.  Without that,
IBM's provider will not be capable of supporting XML Encryption,
period.  Other than IBM adding support, the only option for IBM's JRE is
to use a 3rd party security provider like Bouncy Castle, which does
support all of these requirements.  And in reality, many people are just
going to do that anyway, even with Sun's JRE.



> You're still 1.5 compliant right? I don't think you can quite state this
> when you use provider specific to single vendor (albeit biggest one!).
> This is hazy area of compatibility...anyhoo.
>   

It's perhaps hazy, but I'm not sure where these things fall wrt 1.5
compliance.  I don't know whether requirements for specific JCA/JCE
crypto algorithms are part of those 1.5 compliance requirements.  I
wouldn't think so, since those are all implemented by providers which
are not actually part of the core libraries (even the JRE "default"
security stack is composed entirely of configurable providers), but I've
not looked into it in detail.

Also, we intend to support 1.4.2 via Retroweaver.  However, Sun's 1.4.2
security provider stack for example did not support the ISO10125Padding
scheme - so any chance of getting XML Encryption working there would
also require using BouncyCastle or another 3rd party security provider.

> Time to watch a movie or something...sheesh.
>   

Hope it was good.  :-)

--Brent