using XML entities to ease adminstration, many SP:s using the same shibboleth2.xml files

[Cantor, Scott]

On 2/27/14, 8:07 AM, "Palle Girgensohn" <girgen at FreeBSD.org> wrote:
>At the start of shibboleth2.xml, I expected to be able to add:
>
><?xml version="1.0" encoding="utf-8"?>
><!DOCTYPE SPConfig [
>	<!ENTITY % environment SYSTEM "entity-definitions.dtd">
>	%environment;
>]>

I definitely do not explicitly support DTD usage, and it shocks me that it
would work at all, but I would have to do some analysis of the code. The
parser settings do not appear to be disabling DTD use, but there is tight
control over external entity resolution, which is the main threat model
the code is concerned with.

>Now, the above is accepted by normal XML tools and validators, but
>shibboleth does something different.

The SP is not an XML editor, and it is not seeking to support that. It has
to take great pains to control parsing to prevent security issues, and
there is no separate parsing of configuration vs. parsing other relevant
XML. There could be, I suppose, but there isn't, primarily because the
code actually permits config to be remotely loaded, thus making it much
like any other runtime parsing case.

>ERROR XMLTooling.ParserPool : fatal error on line 2, column 21, message:
>internal subset is not allowed when reusing the grammar

I don't have any idea what Xerces means by that, unfortunately, but the
general answer is that DTDs are not a part of XSD-based technology like
SAML. The parsing code it not meant to handle them other than to prevent
security issues.

>Shibboleth accepts the setup if I change the DOCTYPE, lying that the
>actual root SPConfig is defined in the entity-definitions.dtd:

I don't speak DTD, so I really don't know what the difference is to the
parser.

>Shibboleth has no problems eating this, and everything is working...
>except that now, editors and other tools scream with errors, "Element
>SPConfig must declared". It isn't declared, I'm aware of that, but this
>is the only way I've managed to shibboleth to do what I want.

I am surprised that "works", and if nothing else I'm concerned enough to
want to make sure I know why. That could easily mean there are security
bugs lurking.

>Question is, what is special about shibboleth's xml parser, why does it
>not accept the normal XML DOCTYPE voodoo, but accepts a buggy setup? Is
>the shibboleth2.xml included into another file somehow?  "internal subset
>is not allowed when reusing the grammar"?

I suspect the message is a Xerces anomaly perhaps.

But Shibboleth's XML parser is not intending in any way to support
"normal" DOCTYPE anything, that ideally would be totally ignored for
security reasons. That won't be changing, and I would not ever count on it
working. If I could prevent it, I would, and might in a future release. Do
not do this.

-- Scott