minimal/no backchannel shibboleth idp configuration

[Paul B. Henson]

> From: Tom Scavo
> Sent: Tuesday, December 16, 2014 3:42 AM
>
> Searching for "back channel" in the Spaces wiki leads to this page:
> https://spaces.internet2.edu/x/8YLYAg

Yes, that's exactly the page I was looking for, thanks much for the pointer.

> However, the above isn't really a shib user issue...

Well, while I suppose the generic question of whether or not to implement the back channel might not be a shib user issue, the details of the implementation after the decision is made seem relevant :).

Such as, the example minimal metadata on the internet2 wiki does not include the NameIDFormat entries that are in the default idp metadata generated by the install:

        <NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
        <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>

Based on https://wiki.shibboleth.net/confluence/display/SHIB2/MetadataForIdP, it looks like the idp itself doesn't pay any attention to them and they are also not consumed by the shibboleth SP? However, in addition to being in the default install metadata, they are also in the example metadata on that page. Is there any particular reason to include or not include these entries in the metadata?

The internet2 example also does not include what appears to be a front channel SAML2 binding that is in the default idp example:

<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" 
                             Location="https://shibboleth.csupomona.edu/idp/profile/SAML2/POST-SimpleSign/SSO" />

If trying to deploy a minimal shib idp, is there any particular reason to include or not include this binding?

Also, if you do not plan to support SAML1 and do not advertise it in metadata, would it be a best practice to also remove the ProfileHandler configuration in handler.xml? And all of the SAML1String AttributeEncoder configuration in attribute-resolver.xml? Or the SAML1 configuration in internal.xml? Or would it be simpler/less problematic to leave the idp configuration at the default including all of the functionality not advertised or intended to be used?

Thanks...