SAML metadata validation try two

[Cantor, Scott]

On 6/7/13 1:11 AM, "Brian Tingle" <Brian.Tingle at ucop.edu> wrote:
>
>Okay; .xsd validation seems to work fine using xerces-j java -classpath
>... sax.Counter -n -np -s -v {$filename}-- but I can't get it to work
>with the xmllint command I found at
>https://wiki.shibboleth.net/confluence/display/SHIB2/MetadataCorrectness .
>  I tried the xmllint command on three unrelated systems and all gave me
>that error.

I don't use it and didn't put it there, so if somebody did, maybe they'll
comment on how it works.

>I'm not sure how to do that.  I just have a test SP, UCOP will be my IdP.
> I just figured out how to get my metadata out of /Shibboleth.sso/Metadata
> -- are you saying I should have <MetadataProvidertype="XML"
> in my shibboleth2.xml that point to my own metadata and then shibd -t?

Pretty much, stick it in a file and test it.

> Just for testing, or should it be that way in production?

There's no reason to do it in production; an SP never uses its own
metadata to do anything, ever, ever, ever. That will never happen under
any circumstances.

You don't actually do the XML part of this for many federations. InCommon
doesn't use XML submission, they have a web form to fill out to produce
the metadata, so it's broken down into its parts.

> If I have this set, then will
>/Shibboleth.sso/Metadata  return my good metadata rather than generated
>metadata?

No. If you want to host a metadata file, you're running a web server, you
don't need any help from Shibboleth to do that. But metadata-based trust
management is not just automatic. If you're operating outside a federation
with established trust models, you would be advised to look at the
TrustManagement pages in the wiki that describe how metadata is used and
what the mitigating controls are.

>This is a hypothetical metadata file based on a previous thread wherein I
>asked about mapping of entityID to applications vs. application
>instances.  Scott said I was going to have to edit my metadata anyway,
>and I'm trying to figure out how to do that so I can better understand
>what my options are and what the tradeoffs are.

You're ahead of 99% of the people doing this, then.

>Am I on the right track as far as repeating the Complex Type EndpointType
>elements with redundant Binding attributes and Location attributes that
>point to -dev, -stg, and production, assuming the one entityID per
>application scenario?

Yes. It looked fine.

But to use an example, don't expose logout endpoints unless you're
guaranteeing that invoking them will do the right things with respect to
your application. (That's premature to even guess most likely, I'm just
making the point.) Your metadata is for describing what you support and
use, not everything possible that the software might do (and not things
you don't use or support). That's the difference between what you start
with and end up with.

-- Scott