Zoom Integration with Shibboleth IdP

[Qian, Yi]

Hello, Tom

Can you explain the last comments, http redirect can't handle the signed SAML. I do not really understand the reason, the SP does not support signing? I don't even know how to ask the question, I tried to google without luck

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Tom Scavo
Sent: Friday, January 23, 2015 8:02 AM
To: Shib Users
Subject: Re: Zoom Integration with Shibboleth IdP

[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:SingleL
> ogoutService 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:NameIDF
> ormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameI
> DFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:tra
> nsient</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:n
> ameid-format:persistent</md:NameIDFormat><md:NameIDFormat>urn:oasis:na
> mes:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:NameIDF
> ormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:Na
> meIDFormat><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
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net