managing untrusted metadata

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

managing untrusted metadata

Tom Scavo
I pulled in some comments made by Scott in another thread. [1] Using
these comments as conversation starters, hopefully we can arrive at a
set of best practices for managing untrusted metadata.

On Fri, Apr 20, 2018 at 11:00 AM, Cantor, Scott <[hidden email]> wrote:
>
> I never rely on remote metadata provided by people that have no idea what they're doing (i.e. most vendors).

Well "never" is pretty strong but I get your drift. I suspect most
seasoned IdP deployers have come to the same conclusion, so the
question is how best to manage untrusted metadata, whatever its
source.

My guess is that deployers simply copy a snapshot of the metadata to
the IdP file system and use FilesystemMetadataProvider to load it upon
startup. Is this the best we can do?

Now we have LocalDynamicMetadataProvider but the uses for this new
functionality are not yet clear (to me). Substituting one
LocalDynamicMetadataProvider for N FilesystemMetadataProviders is
enticing but the file names in
LocalDynamicMetadataProvider/@sourceDirectory are opaque and therefore
difficult for a human to identify and manage (or so I think).

To all: If you're using LocalDynamicMetadataProvider today, please
weigh in with your experiences.

Personally, I like the way Peter manages untrusted metadata using git
[2] but he doesn't say how the metadata is ultimately consumed by the
IdP. Maybe he can chime in with more info... (Peter?)

On Wed, Apr 18, 2018 at 11:01 AM, Cantor, Scott <[hidden email]> wrote:
>
> I would never pull in a third party metadata source outside of InCommon or another similarly managed source, at least absent other assumptions that I have never seen a vendor meet.

This comment is similar to the previous one but since InCommon is
mentioned, let me ask: How do folks manage specific entities in
federation metadata (InCommon or otherwise) that happen to be
untrusted? As you know, just because an entity is registered by a
federation does not guarantee the metadata can be trusted. Please
share your experiences here.

On Fri, Apr 20, 2018 at 10:53 AM, Cantor, Scott <[hidden email]> wrote:
>
> You'll recall I tentatively asked about InCommon supporting [the NameIDFormat element in metadata], but then I realized after asking that it was pointless, no services can know (nor do they care) which Format they'll be getting from any given IdP.

Some services *do* care about NameID. I believe there are a fair
number of services that can't consume SAML Attributes and therefore
they care a lot about NameID, which (to them) is all there is.

In any case, InCommon is an outlier with respect to NameIDFormat,
@WantAssertionsSigned, RequestedAttribute, and a few other metadata
bits, which you'll find throughout eduGAIN metadata. In some cases,
these metadata bits are carefully curated and therefore quite useful,
while in other cases they are not at all curated, mostly useless, and
even counterproductive.

Perhaps the most important element in SP metadata is the KeyDescriptor
element yet the absence or presence of that element does not really
tell the IdP deployer what s/he wants to know: Does the SP support
inbound XML encryption? More importantly, does the SP support seamless
encryption key rollover?

Anyway, my point is: Federation metadata may contain untrusted
entities, in which case, what is the best way to manage them?

Tom

[1] https://marc.info/?t=152388658300001&r=1&w=2&n=30
[2] https://marc.info/?l=shibboleth-users&m=150965483025963&w=2
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: managing untrusted metadata

Cantor, Scott E.
> My guess is that deployers simply copy a snapshot of the metadata to the IdP
> file system and use FilesystemMetadataProvider to load it upon startup. Is
> this the best we can do?

I have a range of options with various scripts to handle conventional systems like Shibboleth and SSP that have consistent metadata, but I handle all the one-offs manually right now. I would prefer to break them up into individual files, and probably will use LocalDynamic for that. Then there's the Unicon work on a GUI that also handles one-offs well and ends up producing a directory usable with that plugin.

> Now we have LocalDynamicMetadataProvider but the uses for this new
> functionality are not yet clear (to me). Substituting one
> LocalDynamicMetadataProvider for N FilesystemMetadataProviders is
> enticing but the file names in
> LocalDynamicMetadataProvider/@sourceDirectory are opaque and
> therefore difficult for a human to identify and manage (or so I think).

Grep? How often do I have to go into the metadata anyway? Hardly ever.

> To all: If you're using LocalDynamicMetadataProvider today, please weigh in
> with your experiences.

Just started, I scripted all of it and used rsync to push it around, it's fine. I have some issues with the code I've already filed bugs on, but for most purposes it's fine if the metadata is relatively static. It needs control over refresh based on the files changing like the SP supports.

> This comment is similar to the previous one but since InCommon is
> mentioned, let me ask: How do folks manage specific entities in federation
> metadata (InCommon or otherwise) that happen to be untrusted? As you
> know, just because an entity is registered by a federation does not
> guarantee the metadata can be trusted. Please share your experiences here.

You're using a different definition of "trust", I treat all the federation metadata as trusted and know that I got it from a reliable source and it hasn't been tampered with. That's all.
 
> Some services *do* care about NameID. I believe there are a fair number of
> services that can't consume SAML Attributes and therefore they care a lot
> about NameID, which (to them) is all there is.

Yes, but they care *nothing* about the Format and so any metadata purporting to claim anything about that is not accurate, to a high degree of certainty.

> Perhaps the most important element in SP metadata is the KeyDescriptor
> element yet the absence or presence of that element does not really tell the
> IdP deployer what s/he wants to know: Does the SP support inbound XML
> encryption? More importantly, does the SP support seamless encryption key
> rollover?

It absolutely tells you the former, that's what it *means*. It does not tell you the latter, which I agree is an issue but to be fair, I care only to some degree for whether the SP breaks itself that way. I care if it handles *my* key rollover. That's what we really have a gap around and that could only be self asserted in the end, or deduced by inference based on the apparent type of software used.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Peter Schober
In reply to this post by Tom Scavo
* Tom Scavo <[hidden email]> [2018-04-26 20:06]:
> Now we have LocalDynamicMetadataProvider but the uses for this new
> functionality are not yet clear (to me). Substituting one
> LocalDynamicMetadataProvider for N FilesystemMetadataProviders is
> enticing but the file names in
> LocalDynamicMetadataProvider/@sourceDirectory are opaque and therefore
> difficult for a human to identify and manage (or so I think).

For the SP but anyway:
https://gist.github.com/peter-/612a09d530a140b5abf804ad06cd1634

Name the XML files anything you like (human-friendly) and run `make`
to create (and remove stale) symlinks with sha1-hashes as file names.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: managing untrusted metadata

Cantor, Scott E.
> Name the XML files anything you like (human-friendly) and run `make` to
> create (and remove stale) symlinks with sha1-hashes as file names.

You can also plug in a different entityID -> filename mapping function in the IdP, if you want to chop the entityID down into a hostname and name it that, etc.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: managing untrusted metadata

Rod Widdowson
In reply to this post by Peter Schober
> Name the XML files anything you like (human-friendly) and run `make`
> to create (and remove stale) symlinks with sha1-hashes as file names.

Neat !

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Tom Scavo
In reply to this post by Cantor, Scott E.
On Thu, Apr 26, 2018 at 7:47 PM, Cantor, Scott <[hidden email]> wrote:
>
> I handle all the one-offs manually right now. I would prefer to break them up into individual files, and probably will use LocalDynamic for that.

In your view, what will become of FilesystemMetadataProvider now that
we have LocalDynamicMetadataProvider. Are there any use cases for the
former?

> Then there's the Unicon work on a GUI that also handles one-offs well and ends up producing a directory usable with that plugin.

If you have a link to the Unicon stuff (or someone from Unicon is
listening in), please add to this thread.

>> To all: If you're using LocalDynamicMetadataProvider today, please weigh in
>> with your experiences.
>
> Just started, I scripted all of it and used rsync to push it around, it's fine.

Is this running on the IdP server or elsewhere?

> I have some issues with the code I've already filed bugs on, but for most purposes it's fine if the metadata is relatively static. It needs control over refresh based on the files changing like the SP supports.

Do you have a relevant pointer (or pointers) into jira?

>> This comment is similar to the previous one but since InCommon is
>> mentioned, let me ask: How do folks manage specific entities in federation
>> metadata (InCommon or otherwise) that happen to be untrusted? As you
>> know, just because an entity is registered by a federation does not
>> guarantee the metadata can be trusted. Please share your experiences here.
>
> You're using a different definition of "trust", I treat all the federation metadata as trusted and know that I got it from a reliable source and it hasn't been tampered with. That's all.

Oh, okay, I thought you were handling some entities in federation
metadata specially due to a perceived high probably of failure at some
point down the road.

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: managing untrusted metadata

Cantor, Scott E.
> In your view, what will become of FilesystemMetadataProvider now that we
> have LocalDynamicMetadataProvider. Are there any use cases for the
> former?

It works better for dealing with metadata that's being changed a lot and if you're scripting everything anyway, it doesn't really make that much difference. Six of one for a lot of cases. Batches take more memory, but are also more efficient at runtime. I'm really just saying I would never, ever create a separate metadata resolver for every individual file, that's insane.

> If you have a link to the Unicon stuff (or someone from Unicon is listening in),
> please add to this thread.

I don't have a link. I think it's in Internet2's github, and I don't know how to get into it.

> Is this running on the IdP server or elsewhere?

My staging system. If you mean the GUI I think they envision that it could, but it probably doesn't have to. They're all Docker centric and I'm not, so I wouldn't trust my interpretation of how any of it is supposed to work.

> Do you have a relevant pointer (or pointers) into jira?

Not off the top of my head, they're filed with pretty obvious titles, and much of it's just personal opinion about how I think things should work. e.g. The dynamic plugins don't cache failure. That means you can't have more than one in a chain without too much overhead and it means the remote dynamic has to be at the end of the chain. The local one isn't as bad, but I want better control over refreshes and would rather see it cache failure also.

> Oh, okay, I thought you were handling some entities in federation metadata
> specially due to a perceived high probably of failure at some point down the
> road.

I configure around some of them if I have reason to, but that's not a trust issue, just an operational one.

The ones I care about are contracted services. If I'm using InCommon for that metadata, I stay relatively aware of what I'm doing, and I'll be adding tags via filters to get a lot of my current behavior expressed more declaratively. Ad hoc SPs are responsible for themselves.

As an example, if I made a (poor) decision to push an SP into InCommon that doesn't support encryption, I know I have to work around that and turn it off since they're forced to supply a key that won't actually work. But if an SP out of the blue decided to do that and then made the mistake of asking me to turn it off for them? Let's just say they wouldn't like my answer, but I'd consider that a fun day at work.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Peter Schober
In reply to this post by Tom Scavo
* Tom Scavo <[hidden email]> [2018-04-26 20:06]:
> This comment is similar to the previous one but since InCommon is
> mentioned, let me ask: How do folks manage specific entities in
> federation metadata (InCommon or otherwise) that happen to be
> untrusted? As you know, just because an entity is registered by a
> federation does not guarantee the metadata can be trusted. Please
> share your experiences here.

There are two aspects here, the first Scott answered: The "untrusted"
aspect from the discussion subject/topic was about people not
sufficiently trusted to automatically load SAML metadata from them
over the network, due to all kinds of changes that might happen to
that metadata.
That's not an issue with all remote metadata loading, especially not
from federation operators such as InCommon.

The other aspect of "trusted metadata" which you may be hinting at is
one I care a lot about when it comes to attribute release (or
NameIDs, doesn't matter as under EU law it's all PII now) and for me
it boils down to "sufficient checks performed during registration"
(and we'll have varying defintions for "sufficient"):

Are the data structures in an SP's SAML Metadata signallings its
desire/need for data simply a wishlist to
$mythical-present-giving-deity by some clueless person?
Or has this information been reviewd/vetted by someone who understands
(1) data protection principles such as minimalism and (2) what most
IDPs of the intended target community are actually willing & able to
release? (Trivial inverse correlation: the less the SP asks for the
more likely it'll be that more IDPs will be able to interoperate.)

(Federations such as InC do not perform such reviews/vetting due
liability issues within the most litigious region on the planet.)

I know my own registration practices well ;) so I can document policy
for our community to follow that says "Release whatever the SP
requests IFF the registrar is eduID.at" -- and it would still be
somewhat safe/sane because the metadata that mediates this request has
been through some form of due diligence (rounds of asking "Do you need
this data?" and "What for you need this data?"), and it was pointed
out what our IDPs are capable of releasing (and what not) and what
they are likely to actually release, etc.

Now if I studied the registration policies of other federation
operators (all 50+ of them in eduGAIN) I might find others who do
"acceptably similar" things, and so I could recommend to our community
of IDPs to "Release whatever the SP requests IFF the registrar is A or
B or C or D or X", covering a lot more ground without raising the risk
level significantly. (And we could even make up some layer of
indirection that says "Registrars that have vetted these kinds of data
within metadata" and we could recommend policies based on that one
indirection instead.)

None of that is likely to lead anywhere, of course, so for now we're
stuck with trying to get R&S (and CoCo) deployed, and try people to at
least use consent (i.e., allow the subject to use the service at their
own risk) for the other 90% of SPs.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: managing untrusted metadata

Cantor, Scott E.
> The other aspect of "trusted metadata" which you may be hinting at is one I
> care a lot about when it comes to attribute release (or NameIDs, doesn't
> matter as under EU law it's all PII now) and for me it boils down to "sufficient
> checks performed during registration"
> (and we'll have varying defintions for "sufficient"):

Ah, right, and for the record, OSU does not release attributes based on anything that's in metadata (except local EntityAttributes I use), so all of that is just ignored by my system. We have a default policy for everything and then we create exceptions for additional data. This does not result in data minimization, but if that were the goal, we would just not operate a usable IdP, can't get more minimal.

GDPR may well push us that way; my university is taking it very seriously, and I don't know if the openly federating model can survive it, honestly, but I suspect consent is about to get a lot more important for me. My registrar shot that down last time I tried, but it's probably going to be either that, or nothing.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Tom Scavo
On Fri, Apr 27, 2018 at 1:57 PM, Cantor, Scott <[hidden email]> wrote:
>
> for the record, OSU does not release attributes based on anything that's in metadata (except local EntityAttributes I use)

I thought OSU supported Research & Scholarship?

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Cantor, Scott E.
On 4/27/18, 2:57 PM, "users on behalf of Tom Scavo" <[hidden email] on behalf of [hidden email]> wrote:

> I thought OSU supported Research & Scholarship?

We satisfy the requirement. We don't look at the tag because we release the required data to all SPs, not just those.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Tom Scavo
In reply to this post by Peter Schober
On Fri, Apr 27, 2018 at 12:32 PM, Peter Schober
<[hidden email]> wrote:
>
> For the SP but anyway:
> https://gist.github.com/peter-/612a09d530a140b5abf804ad06cd1634
>
> Name the XML files anything you like (human-friendly) and run `make`
> to create (and remove stale) symlinks with sha1-hashes as file names.

This is nice :-)

I don't know 'make' but I think the script removes all existing
symlinks and then iterates over the XML files to create new symlinks.
If so, then there's a time interval (per XML file) for which no
symlink exists. The more XML files, the longer the time lag
(especially for the files at the end of the list). I suppose this time
lag doesn't matter much in practice.

AFAICT the 'sed' command is intended to remove a two-character prefix
(./) from the output of 'find'. In that case, I believe the dot (.)
should be escaped (\.) but again in practice it probably doesn't
matter.

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Tom Scavo
In reply to this post by Cantor, Scott E.
On Fri, Apr 27, 2018 at 1:28 PM, Cantor, Scott <[hidden email]> wrote:
>
>> Is this running on the IdP server or elsewhere?
>
> My staging system. If you mean the GUI...

No, I'm wondering if there's any value to running this metadata
management system off-IdP. Not for you perhaps but in general.

> As an example, if I made a (poor) decision to push an SP into InCommon that doesn't support encryption, I know I have to work around that and turn it off since they're forced to supply a key that won't actually work.

That's exactly the kind of example I was looking for. Instead of
configuring an exception, one could filter the encryption certificate
from the metadata (assuming the tools exist). Wouldn't that be
preferable?

Taking this to its logical conclusion, most (if not all) integrations
boil down to metadata manipulation. Even attribute release can be
controlled by metadata (add the necessary RequestedAttribute elements
and tag the entity as "locally vetted" or something like that). Is
this a goal?

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Cantor, Scott E.
On 4/27/18, 3:30 PM, "users on behalf of Tom Scavo" <[hidden email] on behalf of [hidden email]> wrote:

> No, I'm wondering if there's any value to running this metadata
> management system off-IdP. Not for you perhaps but in general.

Well, I don't run it *on* the IdP. My staging system is separate. I run a dev IdP mirror instance there for my own use, but that's incidental. I always stage everything I do and it gets pushed over with rsync into production.
 
> That's exactly the kind of example I was looking for. Instead of
> configuring an exception, one could filter the encryption certificate
> from the metadata (assuming the tools exist). Wouldn't that be
> preferable?

Well, in the abstract yes, but that option to disable encryption that way is something I've certainly had cause to reconsider due to the importance of encryption again. As it stands now, yes, I'd prefer it, but I might end up reverting that option so removing the key wouldn't turn off encryption, it would just result in an error.

> Taking this to its logical conclusion, most (if not all) integrations
> boil down to metadata manipulation. Even attribute release can be
> controlled by metadata (add the necessary RequestedAttribute elements
> and tag the entity as "locally vetted" or something like that). Is
> this a goal?

https://wiki.shibboleth.net/confluence/display/IDP30/MetadataDrivenRelyingPartyConfiguration

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Tom Scavo
On Fri, Apr 27, 2018 at 3:37 PM, Cantor, Scott <[hidden email]> wrote:
> On 4/27/18, 3:30 PM, "users on behalf of Tom Scavo" <[hidden email] on behalf of [hidden email]> wrote:
>
>> Taking this to its logical conclusion, most (if not all) integrations
>> boil down to metadata manipulation. Even attribute release can be
>> controlled by metadata (add the necessary RequestedAttribute elements
>> and tag the entity as "locally vetted" or something like that). Is
>> this a goal?
>
> https://wiki.shibboleth.net/confluence/display/IDP30/MetadataDrivenRelyingPartyConfiguration

Do you mean this?

https://wiki.shibboleth.net/confluence/display/IDP30/MetadataDrivenConfiguration

Here's the permalink for the archives:

https://wiki.shibboleth.net/confluence/x/QQInAQ

Thanks,

Tom
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: managing untrusted metadata

Peter Schober
In reply to this post by Tom Scavo
* Tom Scavo <[hidden email]> [2018-04-27 21:13]:
> I don't know 'make' but I think the script removes all existing
> symlinks and then iterates over the XML files to create new symlinks.

No.

> AFAICT the 'sed' command is intended to remove a two-character prefix
> (./) from the output of 'find'.

I've removed the whole pipe (including sed), it's now in a
(non-"secret") gist at:
https://gist.github.com/peter-/a14dd27c4eece331f8c54979972a15f4

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]