minimal/no backchannel shibboleth idp configuration

[Tom Scavo]

On Tue, Dec 16, 2014 at 3:42 PM, Paul B. Henson <henson at csupomona.edu> wrote:
>> From: Tom Scavo
>> Sent: Tuesday, December 16, 2014 3:42 AM
>
>> 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 :).

Fair enough.

> 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?

It doesn't hurt for the software to spit these out. In fact, it
probably should do so for completeness. That's not a good enough
reason to put them in federation metadata, however (which is what I
think you're driving at).

> 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?

If you're asking should it be included in federation metadata, I'd say
no since I seriously doubt it's ever used in practice.

> 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?

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. For instance, you can
support standard IdP-initiated SAML1 flows without advertising SAML1
in metadata. I would try to draw the line there if possible.

Just my two cents,

Tom