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

Re: Shibboleth 2 IdP compatibility



Eric Rybski wrote:
>    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

Sooner you get this type of material to me, the sooner I support gcc-2.96
by default. I am certainly interested in ensuring widest possible C
compiler support.

Regarding mod_perl stability: I would assume most of that has to do
with underlying memory allocator. All allocation activity in zxid code
goes through zx_alloc() (in zxlib.c:55). The ctx->malloc_func function
pointer is not currently used. I should fix zx_alloc() to use it.
Anyway, all this is in place to ensure that you could replace malloc()
with an alternative allocator, such as Apache pool allocator.

In playing with allocators, important caveat: OpenSSL has similar
vectorable allocator. You should use same allocator for OpenSSL and
ZXID (and perl). libcurl documentation is not entirely clear regarding
its allocator usage, but I assume it uses malloc() so that would be
yet another worry.

> 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)

Ok, I got the metadata from https://idp.testshib.org/idp/shibboleth
and will be debugging this. THere will still probably be warnings,
but I promise to fix the errors.

> 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.

Agreed.

> 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.

Right. THer thread safety fixes of 0.51 also affected namespaces
if context was shared from multiple threads. I would imagine this
to be a real possibility in the mod_perl environment.

I'll try to squeeze 0.53 out later this week.

Cheers,
--Sampo

> 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]