Back-channel usage

[Baron Fujimoto]

On Thu, Mar 31, 2016 at 09:44:07PM +0000, Cantor, Scott wrote:
>> I apologize for the what's probably a dumb question, but how do I know
>> what back-channel protocols we currently have defined?
>
>Defined in...? Your old IdP? A default V3 install?

Yes, in our old/current IdP v2.

>> I'm assuming,
>> based on our idp metadata and the information the the following pages
>
>The only metadata that matters is what somebody else sees. InCommon. etc. And that isn't what you "have defined", it's what you advertise. It's possible because of mistakes to advertise something you don't really have configured. The other way around is also certainly possible.
>
>> That we are supporting:
>> 
>> SAML1/SOAP/ArtifactResolution
>> SAML2/SOAP/ArtifactResolution
>> SAML1/SOAP/AttributeQuery
>> SAML2/SOAP/AttributeQuery

It seems that for the InCommon metadata we provide, we only advertise (if
I'm getting this right) the SAML2/SOAP/AttributeQuery protocol. It's
possible for other SPs who are not InCommon members that we may provided
the idp metadata file that I think was created when we originally set up
the IdP v2 with the fuller complement of protocols above.

If this metadata represents what we are advertising, then 
the endpoints(?) that the IdP is actually to handle is configured
elsewhere? Is there any reason to muck the configuration of endpoints
we don't advertise?

>That is the typical situation historically and is what V3 comes configured with (plus Logout I guess).
>
>> Are these the back-channel protocols, or am I already on the wrong track?
>
>Yes, the back channel endpoints all have /SOAP in them right now except for CAS stuff.
>
>> I don't think any of our SPs have requested them, and I don't see any
>> instances of these strings in any of our IdP logs (except where they are
>> loaded as a profile handler for the request path). Is this sufficient
>> evidence that they are not actually being used with our IdP?
>
>The web access logs are the absolute definitive evidence.

Ok, thanks, will also search for confirmation there.

Another of InCommon's upgrade recommendations is to "remove unnecessary
certificates from metadata". We have the same X509 certificate embedded
in both an IDPSSODescriptor and AttributeAuthorityDescriptor in our
metadata. Presumably we at least need the IDPSSODescriptor, but I'm not
sure what AttributeAuthorityDescriptor is for or whether it's also
necessary and should be left in place.

>-- Scott

-baron
-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum