IdP 8443 (v3.2.1)

[Jann Malenkoff]

Thanks Nate -- succinct and much appreciated!

On Fri, Jun 3, 2016 at 8:58 PM, Nate Klingenstein <ndk at sudonym.me> wrote:

> 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" />
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
> --
> 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/711ae13d/attachment.html>