minimal/no backchannel shibboleth idp configuration

[Tom Scavo]

On Tue, Dec 16, 2014 at 5:01 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 12/16/14, 9:45 PM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>>Well, I'm hoping someone on the project team (or anyone else) can
>>weigh in here but I'm hoping an IdP can support SAML1 at some level
>>but avoid advertising it in federation metadata.
>
> Yes, that is one of many reasons why it's a terrible idea to expose
> metadata generated on the fly from a configuration if it's self-published.

Good point.

The following are mostly federation-level considerations but here's
what I tell new IdP deployments:

- An IdP can support IdP-initiated SAML1 flows without advertising
*any* SAML1 endpoints in metadata. (Same is true of SAML2 of course.)

- An IdP supports SP-initiated SAML1 flows by advertising a
SingleSignOnService endpoint that supports the proprietary Shibboleth
AuthnRequest binding/protocol.

- An IdP should avoid SAML1 attribute query if possible. If an IdP
must support SAML1, the IdP should consider pushing attributes via
unencrypted SAML1 assertions on the front channel in lieu of attribute
query.

Of course if every SP supported SAML2, we'd have a different set of
issues to consider:

- An IdP supports SP-initiated SAML2 flows by advertising a
SingleSignOnService endpoint that supports the SAML2 HTTP-Redirect
binding. Support for other bindings is optional and new deployments
are encouraged to be conservative in this respect.

- An IdP should avoid SAML2 attribute query altogether. (I've never
known an IdP deployment that actually needed a SAML2 AttributeService
endpoint in metadata.)

- An IdP should push attributes via encrypted SAML2 assertions when it
can. In practice, expecting all SP software to fully support XML
Encryption is unreasonable, especially for non-Shibboleth SP software,
so IdPs should be prepared to make exceptions.

That said, end-to-end encryption is certainly a goal. An SP that fully
supports XML Encryption belongs to a desirable category of SPs that
should be tagged as such in metadata.

There's a lot of room for other recommendations so take these with a
grain of salt.

Tom