users Digest, Vol 72, Issue 134

Wed Jun 21 14:02:15 EDT 2017

Peter,

When you say "relying" .. Do you mean the dictionary meaning or
configuring the party in the relying party xml.

===========================

Thank You;

Chris Cheltenham
Technology Services
The School District of Philadelphia

Work # 215-400-5025
Cell # 215-301-6571
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of
users-request at shibboleth.net
Sent: Wednesday, June 21, 2017 1:39 PM
To: users at shibboleth.net
Subject: users Digest, Vol 72, Issue 134

Send users mailing list submissions to
	users at shibboleth.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
	users-request at shibboleth.net

You can reach the person managing the list at
	users-owner at shibboleth.net

When replying, please edit your Subject line so it is more specific than
"Re: Contents of users digest..."

Today's Topics:

   1. Re: Signing metadata (Peter Schober)
   2. Re: Signing metadata (Larissa Riedel)
   3. Re: Signing metadata (Larissa Riedel)
   4. Re: Signing metadata (Cantor, Scott)

----------------------------------------------------------------------

Message: 1
Date: Wed, 21 Jun 2017 18:54:03 +0200
From: Peter Schober <peter.schober at univie.ac.at>
To: users at shibboleth.net
Subject: Re: Signing metadata
Message-ID: <20170621165403.GD29472 at aco.net>
Content-Type: text/plain; charset=us-ascii

* Larissa Riedel <larissa.riedel88 at gmail.com> [2017-06-21 18:20]:
> I'm aware of how metadata is usually created. I've also already used 
> the XMLSecTool to sign metadata of an example federation.
> 
> The scenario consists of a single IdP and a single SP with both not 
> being in a federation. I'm trying to distribute the metadata 
> (automatically
> signed) in both directions via https.

How is trust established between those entities, then? By manually
exchanging and configuring certificates at each party (as part of a
signature validation filter)? By relying on PKIX and signing the metadata
with keys that have CA-signed certificates?

-peter

------------------------------

Message: 2
Date: Wed, 21 Jun 2017 19:27:44 +0200
From: Larissa Riedel <larissa.riedel88 at gmail.com>
To: Shib Users <users at shibboleth.net>
Subject: Re: Signing metadata
Message-ID:

<CADcSn1LyuNcs8EH6t9ssOVncUVjkph=bzdszTHpHMdDvCkBADA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Scott,

thanks for the help! So generating and signing the metadata on the fly is
only feasible for testing environments and in production environments the
SP and IdP Metadata should be distributed from static files?

Would you mind giving me a more in depth explanation why that gap is
necessary? Unfortunately I don't understand the reasoning.

To verify my understanding: The usual way would be that the "federation"
retrieves the static metadata of all SPs and IdPs every X hours, verifies
each of them and then creates the federation metadata file and sign it?

Larissa
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://shibboleth.net/pipermail/users/attachments/20170621/76b28b26/attac
hment-0001.html>

------------------------------

Message: 3
Date: Wed, 21 Jun 2017 19:36:13 +0200
From: Larissa Riedel <larissa.riedel88 at gmail.com>
To: Shib Users <users at shibboleth.net>
Subject: Re: Signing metadata
Message-ID:

<CADcSn1+uupZAtzdza5JrpqABH+yyfvLtYHvT+ZhFgfQeD=71jQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Peter,

> How is trust established between those entities, then? By manually 
> exchanging and configuring certificates at each party (as part of a 
> signature validation filter)? By relying on PKIX and signing the 
> metadata with keys that have CA-signed certificates?

Yes trust is established by exchanging and configuring certificates at
each party.
I understand that there is no real practical use for that scenario and
that there would a lot overhead included if used in that way. The sole
reason for this scenario was to describe a very minimalistic example of
how trust is established with shibboleth.

Larissa
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://shibboleth.net/pipermail/users/attachments/20170621/b9a61d50/attac
hment-0001.html>

------------------------------

Message: 4
Date: Wed, 21 Jun 2017 17:39:00 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: Signing metadata
Message-ID: <1D1897DA-D9DB-42F4-A347-655A920708C8 at osu.edu>
Content-Type: text/plain; charset="utf-8"

On 6/21/17, 1:27 PM, "users on behalf of Larissa Riedel"
<users-bounces at shibboleth.net on behalf of larissa.riedel88 at gmail.com>
wrote:

> thanks for the help! So generating and signing the metadata on the fly 
> is only feasible for testing environments and in production environments
the SP and IdP Metadata should be distributed from static files?

They don't have to be static, they do have to be decoupled from the actual
configuration of a system.

> Would you mind giving me a more in depth explanation why that gap is 
> necessary? Unfortunately I don't understand the reasoning.

The most prevalent use case for automated metadata exchange is changing a
key. The SP has no facility for adding a key at runtime that doesn't end
up in the generated metadata, or including a key in the metadata before it
gets into the runtime. Part of the process for changing a key involves a
guarantee that a key won't get used until after the metadata change
propagates or a guarantee that the key can be used before it ends up in
the metadata. By definition then, you can't use metadata for the most
important thing it's meant to be used for in an automated situation if you
generate it with no intervening gap or you'll end up with an outage.

> To verify my understanding: The usual way would be that the 
> "federation" retrieves the static metadata of all SPs and IdPs every X
hours, verifies each of them and then creates the federation metadata file
and sign it?

Most federations rely on a manual process of operators registering changes
to their metadata via strongly authenticated access. The propagation of
the changes is automated, not the receipt of the changes.

 -- Scott

------------------------------

Subject: Digest Footer

--
To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net

------------------------------

End of users Digest, Vol 72, Issue 134
**************************************