testing errors

Tom Scavo trscavo at gmail.com
Tue Jan 16 11:09:47 EST 2018


On Tue, Jan 16, 2018 at 5:22 AM, Rod Widdowson <rdw at steadingsoftware.com> wrote:
>> Rod, I don't see what LocalDynamicMetadataProvider has to do with it.
>> Could you briefly outline the administrator workflow you have in mind?
>
> My suggestion was based on the potentially flawed observation that most outages are due to broken pushed metadata.  This takes out
> the entire site until such time as it is found and fixed.

Yes, exactly. If TestShib is going to distribute an aggregate, users
should not be allowed to push raw XML into the system. That is unsafe,
as we are seeing.

Btw, InCommon learned this lesson long ago (namely, "the aggregate is
brittle"). Users upload metadata bits via HTML forms. On the back end,
an aggregate is constructed from the metadata bits input by the user.
Thus the entity descriptors are homogenous throughout the published
aggregate.

> A secondary observation is that the user has to remember the name of their metadata file which is a needless burden and I see
> occasional request to "delete my old metadata whose name I have forgotten"

Good point. I've been thinking about Peter's suggested workflow for
managing local (untrusted) metadata [1] and it has the same problem:
how to name the git-managed files in the filesystem. Unfortunately,
that problem doesn't go away if you use a LocalDynamicMetadataProvider
store (more on that below).

> So knowing that the way that the LocalDynamicMetadataProvider works is to, _in the context of the request_
>
> 1) Hash the provided entity ID
> 2) Look for a file of that name in a specified directory
> 3) Load it parse it and so forth.
>
> We can see that both problems are avoided.

Are you saying that TestShib should go away and users should use the
new metadata capabilities of Shibboleth?

In any case, it's important to note that the problems you've
identified are addressed by DynamicMetadataProvider as well. In
particular, like LocalDynamicMetadataProvider, there is no aggregate.

> If the metadata is badly formed it takes out the request, not the TestShib SAML Entity.

I would say that is a benefit of per-entity metadata more generally.
Clearly (to me), if TestShib is to survive, it should evolve into a
metadata query server (i.e., a server that conforms to the metadata
query protocol) but then it competes with other MDQ servers and we
have InQueue all over again.

> The user doesn't specify a file name, it is generated for them.

I don't quite get that. The source directory of a
LocalDynamicMetadataProvider is a read-only metadata store. The actual
metadata files to be managed are stored somewhere else. Unless I'm
missing something, LocalDynamicMetadataProvider does not work around
the file naming issue.

OTOH, if TestShib became an MDQ server, this problem goes away since
metadata addressability is a function of the entityID.

> Just FWIW

Thanks Rod.

Tom

[1] https://marc.info/?l=shibboleth-users&m=150965483025963&w=2


More information about the users mailing list