[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shibboleth 2 IdP compatibility



Hi Sampo,

   There are several custom features, mod_perl stability patches, and build
support for gcc 2.96 I added for my client that will take time to port
forward from 0.32 to a new patch for 0.52.  This represents a reasonable
effort, unfortunately, including regression testing.  So I'm willing to
consider an upgrade if I have no other choice, but I'm really hoping to
apply incremental modifications to the 0.32 release first.  In the case of
what I need, the support is (theoretically) version independent.

   Regarding Shibboleth support, I can't even parse the testshib IdP
metadata right now with 0.32.  The metadata (
https://idp.testshib.org/idp/shibboleth), which I've added to my COT as the
file hash name "0D5XlTNF5XoaggdNLUd8nKON-XY", returns the following parsing
error:

t c/zx-dec.c:589 zx_DEC_wrong_elem zx E Mismatching close tag(shibmd:Scope)
tok=-2 context=-2
t    zxlib.c:877 zx_xml_parse_err zx E zx_DEC_wrong_elem: Mismatching close
tag: char(-) pos=573 (ib.org</shibmd:Scope></Extensions><KeyDe)

This is where last left off and began to try to import the shibboleth xsd
into zxid.  Theoretically, you are correct in that I can probably ignore
most (all?) of the extensions, at least in a practical sense.  But zxid does
need to be able to handle these cases without error.

And it seems like namespace (data type) support for these extensions is the
primary piece I'm missing to at least get basic Shib<->zxid interoperability
working.  (Please correct me if I'm wrong here.)

In terms of unknown namespace support, are there other (not in release
notes) changes that have occurred between 0.32 and 0.52?  I've been
following the release notifications, and it seemed like 0.49-0.50 was the
primary update on this subject so far since 0.32.

Thanks,
Eric

On Fri, Feb 19, 2010 at 7:08 PM, <sampo@xxxxxxxxxxx> wrote:

> Eric Rybski wrote:
> > Hi Sampo,
> >
> >    I see that you added shibboleth namespaces in the 0.42 release.
> > Thanks!
>
> Just adding namespace is not enought, unfortunately.
>
> > But I'm currently locked into the 0.32 release in my environment (a
> > production stable integration), so I'm planning to back-port the
> namespace
> > support into 0.32.
>
> In current releases, like 0.52, the unknown namespace support has
> improved a lot. So you are facing a situation where by adopting a
> newer release your namespace would be supported, and even if it was
> not, it would be generically supported much better than it ever was/will
> be in 0.32. To this backdrop, backporting support to 0.32 does
> not make much sense.
>
> I understand that you may have external reason why it must be 0.32, but
> porting these features to 0.32 is about as risky (or even more risky)
> as simply upgrading to 0.52.
>
> > Is there any easy way to determine what needs patching and what doesn't
> to
> > import support for these namespaces?  I did a grep and saw many files
> > involved.  I was considering a diff of 0.41 to 0.42 as a starting point.
>
> Namespace support is generally achieved throught code generation methods,
> mostly by xsd2sg.pl, which in standard distribution is not invoked.
> A given namespace articulates with the rest of the system through
> c/zx-ns.h and c/zx-ns.c, plus the namespace dependent files, which
> may be many. Additionally, a namespace is relevant only if it
> is referenced somewhere else. The most common place to reference
> is in c/zx-e-data.h and other files of the SOAP Envelope namespace.
>
> > Or perhaps it's a better idea to rebuild my 0.32 distribution with the
> > Shibboleth *.sg files?  Is this generally as simple as altering the
> > Makefile
> > to be aware of the new SG files?
>
> Not sure. Certainly altering the Makefile is possible, but I am not
> sure if that is sufficient to achieve what you want to achieve.
>
> I need more feedback about Shibboleth. So far my experience has been
> that Shibboleth metadata can be processed successfully by simply
> ignoring the Shibboleth extentions to the metadata. In many practical
> situations the Shibboleth extentions seem irrelevant (or may be I have
> failed to grasp their significance from their documentation).
>
> Cheers,
> --Sampo
>
> > Thanks,
> > Eric
> >
> > zxid-0.50]$ grep -ril shib *
> > Changes
> > Makefile
> > Manifest
> > README.zxid
> > c/zx-elems.c
> > c/zx-md-aux.c
> > c/zx-md-dec.c
> > c/zx-md-enc.c
> > c/zx-shibmd-aux.c
> > c/zx-shibmd-dec.c
> > c/zx-shibmd-enc.c
> > c/zx-data.h
> > c/zx-md-getput.c
> > c/zx-ns.c
> > c/zx-ns.h
> > c/zx-ds-data.h
> > c/zx-md-data.h
> > c/zx-enc.c
> > c/zx-shibmd-data.h
> > c/zx-shibmd-getput.c
> > c/zx-const.h
> > csharp/zxid.cs
> > csharp/zxidPINVOKE.cs
> > sg/shibboleth-metadata-1.0.sg
> > sg/saml-schema-metadata-2.0.sg
> > zx/c/zx-elems.c
> > zx/c/zx-md-aux.c
> > zx/c/zx-md-dec.c
> > zx/c/zx-md-enc.c
> > zx/c/zx-shibmd-aux.c
> > zx/c/zx-shibmd-dec.c
> > zx/c/zx-shibmd-enc.c
> > zx/c/zx-data.h
> > zx/c/zx-md-getput.c
> > zx/c/zx-ns.c
> > zx/c/zx-ns.h
> > zx/c/zx-ds-data.h
> > zx/c/zx-md-data.h
> > zx/c/zx-enc.c
> > zx/c/zx-shibmd-data.h
> > zx/c/zx-shibmd-getput.c
> > zx/c/zx-const.h
> > zx/sg/shibboleth-metadata-1.0.sg
> > zx/sg/saml-schema-metadata-2.0.sg
> > grep: warning: zx/zx: recursive directory loop
> >
> > zx/zxid-idp.pd
> > zx/Makefile
> > zx/Manifest
> > zx/zxid-ref.pd
> > zx/Changes
> > zx/csharp/zxid.cs
> > zx/csharp/zxidPINVOKE.cs
> > zx/zxidjava/zxidjniConstants.java
> > zx/zxidjava/zxidjniJNI.java
> > zx/zxidjava/zxid_wrap.c
> > zx/README.zxid
> > zxid-idp.pd
> > zxid-ref.pd
> > zxidjava/zxidjniConstants.java
> > zxidjava/zxidjniJNI.java
> > zxidjava/zxid_wrap.c
> >
> >
> > On Tue, Oct 13, 2009 at 7:41 AM, <sampo@xxxxxxxxxxx> wrote:
> >
> >> Unless you already integrated, can you send me the schema and I'll
> >> integrate it.
> >>
> >> Cheers,
> >> --Sampo
> >>
> >> Eric Rybski wrote:
> >> > Hi,
> >> >    I'm trying to connect a zxid 0.32-based SP to to a Shibboleth 2.1
> >> IdP
> >> (
> >> > https://www.testshib.org).  The metadata (
> >> > https://idp.testshib.org/idp/shibboleth) for this instance implements
> >> > namespaces which zxid does not currently support, like
> >> > "urn:mace:shibboleth:metadata:1.0".
> >> >
> >> > I've been following documentation for adding new namespaces:
> >> >
> >> >
> >>
> http://www.zxid.org/html/README.zxid-17README_zxid-CreatingNewInterfacesUsingZXIDMethodology.html
> >> >
> >> > I'm now at step 2: manual tweaking of SG files.  I'm not sure I'm
> >> > modifying
> >> > files correctly, as I don't have clear examples as to how the SG
> >> results
> >> > should look given different XML cases (primarily steps 2.2 and 2.3).
> >> It's
> >> > also unclear whether I need to make any changes specific to step 2.1.
> >> >
> >> > For example:
> >> >    - As per step 2.3, I changed one occurence of
> >> > @xml:lang?
> >> >
> >> > to:
> >> > @xml:lang? -> %xs:string  #@xml:lang vs. @lang   ***".
> >> >
> >> >    - As per step 2.2, I changed:
> >> > %SiteGroupType:
> >> >     shib:OriginSite
> >> >  |   shib:DestinationSite
> >> >  |   shib:SiteGroup
> >> >
> >> > to:
> >> > %SiteGroupType:
> >> >     shib:OriginSite
> >> >     shib:DestinationSite*
> >> >     shib:SiteGroup*
> >> >
> >> > given XML definition:
> >> >         <sequence>
> >> >             <choice maxOccurs="unbounded">
> >> >                 <element ref="shib:OriginSite"/>
> >> >                 <element ref="shib:DestinationSite"/>
> >> >                 <element ref="shib:SiteGroup"/>
> >> >             </choice>
> >> >             <element ref="ds:Signature" minOccurs="0"/>
> >> >         </sequence>
> >> >
> >> >
> >> > Are these accurate modifications?  I've attached copies of the
> >> unmodified
> >> > (no manual tweaks) .sg files I generated, as well as the original XSD
> >> > files,
> >> > for reference.
> >> >
> >> >    If anyone has more experience building "correct" .sg files, I'd
> >> greatly
> >> > appreciate help getting these SG files updated.  Once correctly
> >> modified,
> >> > perhaps these could also be included in the zxid distribution for
> >> > out-of-the-box compatibility with Shibboleth 2 identity providers.
> >> >
> >> > Note: The archive also includes my modified xsd2sg.pl, as there were
> a
> >> few
> >> > elements, attributes, and syntax constructs implemented in the
> >> Shibboleth
> >> > XSD files that were not being handled.
> >> >
> >> > Regards,
> >> > Eric
> >> >
> >> > [demime 1.01d removed an attachment of type application/zip which had
> >> a
> >> > name of shib_2.2.1_sg.zip]