Skip to Content.
Sympa Menu

mace-opensaml-users - RE: OpenSAML version nightmare

Subject: OpenSAML user discussion

List archive

RE: OpenSAML version nightmare


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>, "'OpenSAML'" <>
  • Subject: RE: OpenSAML version nightmare
  • Date: Tue, 15 Nov 2005 17:16:17 -0500
  • Organization: The Ohio State University

> - Will C++ OpenSAML 0.8 produce SAML 1.1 authentication assertions?

Yes, with the caveat that 0.8 is riddled with bugs, and some may be fatal
for applications using it. I simply can't vouch for anything like that.
Signing is for sure questionable back that far in the C++.

> - Will Java OpenSAML 0.8 consume authentication assertions produced by
> C++ OpenSAML 0.8?

Yeah, mostly likely. Authentication statements (not queries) were done early
on since Shibboleth used them.

> - Will Java OpenSAML 1.1 consume authentication assertions produced by
> C++ OpenSAML 0.8?

I would think so.

> - Will a SAML 2.0 metadata library compatible with OpenSAML 1.1 be
> provided? If so, when?

There will not be any special use of the new metadata code in any of the
older code, since it's not there now. I wouldn't anticipate there being a
problem using both libraries at once in either Java or C++, although it
doesn't look like Shibboleth will require that (see next question). There
will not be any sort of "metadata library", though (see below).

> - Will OpenSAML 2.0 produce and consume SAML 1.1 assertions?

It appears so, natively (not by just coexisting with the old library).
That's not a promise, but that's where we seem to be going.

> - When will OpenSAML 2.0 beta be available for testing?

Definitely not until next year for anything resembling a beta. There might
be a way to release a snapshot with a completed metadata implementation plus
supporting classes, but the problem is that I have no intention of allowing
that early a code drop to find its way into other products, or we're just
making this mess worse, I think.

For metadata consumption purposes, borrowing the Shibboleth code is a much
better way to go.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page