IdP 8443 (v3.2.1)

[Nate Klingenstein]

Jann,

There’s the technical answer, and there’s the philosophical answer.

Philosophically, it was decided to use a separate port for TLS-secured and -mutually-authenticated communications between the IdP and the SP to enable usage of client-facing credentials on 443 without forcing their use in federated transactions.

This is how early versions of Shibboleth worked, and many SSO protocols still work this way.  There are serious deployment burden downsides to the use of the back channel, but there are also very important use cases that it makes possible.

That specific binding advertises that your IdP is ready, willing and able to answer SAML 2.0 AttributeQuery requests issued directly by SP’s to that endpoint.  Whether that’s true or not gets into the wiring you have behind it.  The only firm recommendation is that your metadata must accurately represent the capabilities of your IdP.

For further exhumation:

https://spaces.internet2.edu/pages/viewpage.action?pageId=98306418#IdentityProviderDiscussionTopics(IdPv3)-8.TheBackChannelKoan

Take care,
Nate.

> On Jun 3, 2016, at 21:30, Jann Malenkoff <jannmalenkoff at gmail.com> wrote:
> 
> There is a bit of a debate going on at or university.
> 
> What exactly is the following used for by the IdP?
> 
> If we use SAML2 - what is the purpose of the back-channel port 8443?
> 
> <AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
>                           Location="https://example.edu:8443/idp/profile/SAML2/SOAP/AttributeQuery <https://example.edu:8443/idp/profile/SAML2/SOAP/AttributeQuery>" />
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160603/e16addad/attachment.html>