Using a second signing certificate

[Cantor, Scott]

On 7/15/13 12:37 PM, "Jason Gauthier" <jgauthier at lastar.com> wrote:
>I acquired my metadata from ADFS:
>https://ADFS/FederationMetadata/2007-06/FederationMetadata.xml

You can't do key rollover unless the metadata is decoupled from the
configuration so that it can be altered ahead of the change. InCommon has
a number of wiki pages that describe how this works in some detail (there
are some in the Shibboleth wiki as well, but more specifically geared to
the software).

But basically you are guaranteed to break if you start signing with a key
before every downstream system has metadata containing that key. I would
imagine that's the source of your problem, but you didn't really provide
specifics as to what the state was when it broke.

>This metadata is signed, and I had to remove all of the signature data
>following these instructions:

Metadata signing is a separate consideration, and depends on how you're
managing trust between systems. But in general you cannot, for the above
reason, rely on ADFS or any other system to directly generate metadata
from a configuration and then expect key rollover to be successful.

In any case, the metadata, once it's in the desired state, can be signed
with various tools if you need to sign it.

>However, when I simply use the metadata straight from ADFS, authorization
>doesn't work because apparent Shibd doesn't like the metadata:

If you want it to honor scope, leave the default filter policy in place.
If not, you can modify it.

But needing to modify the metadata generated by a software product is the
norm, not the exception, because of how it's used.

-- Scott