Metadata, examples, best practices?

[Jason Gauthier]

Great, thanks! That was extremely helpful regarding ADFS, and I will go ahead and implement the metadata manually, and update changes manually.
It's just me, and my ADFS, so no worries.

> You should never use a commercial TLS certificate for SAML purposes, ever. That model is very flawed and you will regret it endlessly

This struck me as interesting, and I wanted to make sure I am not going about something completely crazy.  Or perhaps a better way for managing this.
I have 3 services on one Apache host. To save certificates/pricing, I used a "wildcard" cert.  (I think it just has multiple subjects, but the idea is the same)

To make this work with ADFS (okay, PLEASE do not criticize this part, as I now understand much of this is wrong, and I am working to redo it)
I pointed the metadata to /Shibboleth.sso/Metadata, and told ADFS to not update it.
I then manually added endpoints for the other two virtual hosts on the relaying party.
I edited shibboleth2.xml and added application overrides like this:
<ApplicationOverride id="myhost2.abc.com" entityID="https:// myhost2.abc.com.com/shibboleth"/>
<ApplicationOverride id="myhost3.abc.com" entityID="https:// myhost3.abc.com/shibboleth"/>

So, as far as certificates go. When a person would hit myhost[1,2,3].abc.com, it would use the same public cert. 
The ADFS relaying part has a signing certificate from "myhost1.abc.com".

Are you saying that I should not use the public cert on the relying party, but actually use a self signed? (this is how I am interpreting commercial TLS)



-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, November 27, 2013 2:56 PM
To: Shib Users
Subject: Re: Metadata, examples, best practices?

On 11/27/13, 2:33 PM, "Jason Gauthier" <jgauthier at lastar.com> wrote:

>I have used shib a few times, and achieved what I wanted to achieve.  I 
>am now setting up something a little more elaborate and I want to get 
>things done well from the beginning.
>For my environment shib is an SP, and ADFS is the IDP.  Just to set the 
>imagery properly.

You have to understand that ADFS is not a fully metadata-capable product, so you're talking about a system in which many of the answers to your questions would result in a non-working metadata file. There's "best practice" and there's "what ADFS can handle".

(You actually found one of those bugs already, the limitation on sharing keys, which is a very major limitation. It misunderstands that the entire point of using metadata for trust is to break the single key per entity assumption. But I should note that you mentioned wildcards. You should never use a commercial TLS certificate for SAML purposes, ever. That model is very flawed and you will regret it endlessly.)

>In ADFS I could go the route of one relaying party with multiple 
>assertion consumer endpoints, or I could make one for each "virtualhost".
>If I make one (maybe that's bad practice) how do I go about adding 
>additional "md:AssertionConsumerService" records to the metadata?
>I attempted to do this, and it came out poorly.

I'd probably need to know what you mean to answer that. The metadata is an XML file, you can cut and paste quite easily. You can also use scripts to generate the metadata fairly easily, one of which is in the SP (but it's a shell script for Linux).

And lastly, if you really want to go through the hassle, you can add all sorts of XML to the Metadata handler in the SP to get it to auto-generate multiple vhost endpoints.

>What is the preferred method to provide this metadata to ADFS? ( which 
>is my only partner, and it's internal)

Well, the preferred method is with a third party federation. If you honestly have one partner, then that's not a routine scenario we're trying to talk about. With one partner, you can exchange the metadata out of band and just communicate when there are changes to it. That doesn't scale and that's what the comment is partly talking about.

>Is that simply copying what is generated automatically and then 
>modifying it for my needs, and then servicing it up as on another URL, 
>or is there any configuration where serving it up from the "generation handler" valid?

If your goal is to host the metadata yourself, then yes, the right model is to separate the metadata you provide from anything generated. Typically be indirecting lookup of metadata via the entityID, which can be redirected to the generator if you really know what you're doing, but then redirected to something else when necessary.

You cannot use metadata properly for things like key rollover if you tie the metadata in real time to the exact configuration of the SP. Under no circumstances should any IdP be accessing /Shibboleth.sso/Metadata. That's the point of the comment.

There are also many kinds of extensions used in Shibboleth based federations that can't be generated.

But to the immediate point, ADFS cannot safely be pointed to remote metadata. That model doesn't work because ADFS can't secure that update properly. ADFS is only safe to use with metadata exchanged out of band.

-- Scott


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