Automating the generation of IdP metadata

[Franck Mangin]

Thanks Scott for the detailed response. 
Our scenario is fairly simple for now, so I will leave back channel protocols out of the picture as you suggest. There is no plan at all to have our IdP join any federation, it is co-installed with our product to provide out of the box SSO authentication; customers can then use that, or point the SP at any corporate/public/federated IdP they wish.

Franck

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, February 12, 2016 8:19 PM
To: Shib Users <users at shibboleth.net>
Subject: RE: Automating the generation of IdP metadata

> So if I understand you correctly I need to open an additional https 
> port on Apache for the ArtifactResolutionService and AttributeService.

No, first you determine whether you need SOAP support [1].

If you do, you can secure that with mutual TLS, generally implying a separate port, or you can use XML signing and encryption, and convince partners to do the same, and use port 443. What you should NOT do, ever, is rely on the browser facing certificate as a credential in your metadata to secure those endpoints.

Historically, Shibboleth has always favored mutual TLS over 8443. In the future, that's probably shifting to 443 and signing because that's the best middle ground to support OAuth and other kinds of technologies that need a back channel.

For now, you should simply not bother with the back channel. I very much doubt you need it.

> Is there any way to modify the 8443 default without editing the auto- 
> generated idp-metadata.xml?

That is a convenience to get people started. Metadata MUST be maintained explicitly to reflect the deployment, changes you make, and how you need to make the changes visible to others. It is meant to be maintained by hand because we provide no tools to do otherwise.

> Also I assume that the SP (or anyone who needs those services) will 
> take the port number from the IDP metadata, so that it's the only 
> place where that port number need to be configure?

They take it from the metadata, but they do not take it from some piece of example metadata and they do not take it from you at all unless they don't understand how this all works. Federations exist to broker trusted metadata between partners. Outside of higher ed, that understanding doesn't exist, but that doesn't mean the problem goes away.

If you want people to consume your metadata directly, you're counting on them not understanding security (which will get you fairly far in fact, but doesn't make it right), or you're looking at an out of band key exchange step and you need a deeper understanding of the trust models involved with this approach to metadata, which includes things like how revocation works in this scenario. [2]

Basically to self host metadata following the IOP profile, you need a separate signing key for it and a process to constantly reissue it with a validUntil date of a few days out to limit your expsoure window.

-- Scott

[1] https://wiki.shibboleth.net/confluence/display/IDP30/SecurityAndNetworking
[2] https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement

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

This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.