Zoom Integration with Shibboleth IdP

[Tom Scavo]

[I'll add a few editorial comments but David's response is really all
you need to know]

On Thu, Jan 22, 2015 at 11:14 PM, Leung, Warren <wleung at it.ucla.edu> wrote:
>
> They do not support encrypted assertions.  From what I’ve seen there have
> been a lot of vendor applications that have their own SAML implementations
> that do not support encrypted assertions.  So I guess this is more of a
> comment than a question/issues.

Yes, that's true. XML Encryption is not well supported at vendor SPs.

> ... looking at the metadata they provided it
> appears that it does not contain any certificate information.  Their support
> provided the following "We do receive iDP cert but we not require SP cert as
> we do not sign requests and response sent to the Identity Provider today.
> The SSO sign-in page is transmitted over https only.”

Given the fact that they don't support XML Encryption, this is a
perfectly reasonable response. In practice, SPs almost never sign the
AuthnRequest (for good reasons) so if the SP doesn't support
encryption, no certificate in SP metadata is necessary.

> The schema allows for
> 0 KeyDescriptors, but I have never run into a scenario where a SP had 0.
> Does anyone have any experience working with this?

As you know, InCommon requires a certificate in SP metadata but we
can't require an SP to support encryption so we get into situations
where SPs essentially advertise encryption support that doesn't exist.
That's actually worse than not having a certificate in metadata at
all.

> I am not even sure if this will work

As David said, it does.

> and if signing isn’t enabled it just doesn’t seem secure.

SPs don't sign today so I'm not sure what the concern is. The IdP
confirms the identity of the SP via trusted metadata so signed
AuthnRequests are a burden more than anything else. As Scott has said
a hundred times, an SP that signs AuthnRequests is a sitting duck for
a DoS attack.

> The metadata I am referring to is below.
>
> <?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor
> xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
> entityID="ucla.zoom.us"><md:SPSSODescriptor AuthnRequestsSigned="false"
> WantAssertionsSigned="true"
> protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><md:SingleLogoutService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
> Location="https://ucla.zoom.us/saml/SingleLogout"
> ResponseLocation="https://ucla.zoom.us/saml/SingleLogout"/><md:SingleLogoutService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> Location="https://ucla.zoom.us/saml/SingleLogout"
> ResponseLocation="https://ucla.zoom.us/saml/SingleLogout"/><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><md:AssertionConsumerService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
> Location="https://ucla.zoom.us/saml/SSO" index="0"
> isDefault="true"/><md:AssertionConsumerService
> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
> Location="https://ucla.zoom.us/saml/SSO"
> index="1"/></md:SPSSODescriptor></md:EntityDescriptor>

I'll make a couple comments about the metadata, just for kicks:

1) The entityID "ucla.zoom.us" would not fly in most federations
(InCommon included) since it is not an absolute URI.

2) The AssertionConsumerService endpoint with HTTP-Redirect binding is
bogus since that binding can't handle a signed SAML response from the
IdP.

Other than that, it should work just fine.

Tom