Integrating idp3 with cirqlive

[Rhian Resnick]

Evening all,


We have implemented Cirqlive and yes this process is as horrible as it sounds. Webex doesn't understand Saml and they don't support defining multiple identify providers (which would have resolved this issue). In the end creating and sharing a custom key and allowing impersonation of all users on the webex site by cirqlive is the only way to setup the integration while preventing cirqlive having access to your federated private key. (It certainly wasn't enjoyable or fun explaining this configuration to our security team)


IDP 3.3 supports the process here is an except from our relaying-party.xml file.


>From relaying-party.xml


 <!-- Configure fau's webex key -->
<bean id="ObnoxiousSecurityConfig" parent="shibboleth.DefaultSecurityConfiguration">
    <property name="signatureSigningConfiguration">
        <bean parent="shibboleth.SigningConfiguration.SHA256" p:signingCredentials-ref="shibboleth.WebexSigningCredential" />
    </property>
</bean>

        <!-- WebEx http://www.webex.com/faulearn -->
        <bean parent="RelyingPartyByName" c:relyingPartyIds="#{{ 'http://www.webex.com/faulearn', 'http://www.webex.com/fau' }}">
            <property name="profileConfigurations">
                <list>
            <bean parent="Shibboleth.SSO" p:securityConfiguration-ref="ObnoxiousSecurityConfig" />
            <bean parent="SAML1.AttributeQuery" p:securityConfiguration-ref="ObnoxiousSecurityConfig" />
            <bean parent="SAML1.ArtifactResolution" p:securityConfiguration-ref="ObnoxiousSecurityConfig" />
            <bean parent="SAML2.ECP" p:securityConfiguration-ref="ObnoxiousSecurityConfig" />
            <bean parent="SAML2.Logout" p:securityConfiguration-ref="ObnoxiousSecurityConfig" />
            <bean parent="SAML2.AttributeQuery" p:securityConfiguration-ref="ObnoxiousSecurityConfig" />
            <bean parent="SAML2.ArtifactResolution" p:securityConfiguration-ref="ObnoxiousSecurityConfig" />
            <bean parent="SAML2.SSO" p:encryptAssertions="false" p:signResponses="false" p:signAssertions="true" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" p:securityConfiguration-ref="ObnoxiousSecurityConfig"  />
                </list>
            </property>
        </bean>

>From credentials.xml


    <bean id="shibboleth.WebexSigningCredential"
        class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
        p:privateKeyResource="%{idp.signing.webex.key}"
        p:certificateResource="%{idp.signing.webex.cert}"
        p:entityId-ref="entityID" />

There are several adjustments that are required to saml-nameid.xml and attribute-resolver.xml to support webex. If you want those configurations please email me off list.



Rhian Resnick

Assistant Director Middleware and HPC

Office of Information Technology


Florida Atlantic University

777 Glades Road, CM22, Rm 173B

Boca Raton, FL 33431

Phone 561.297.2647

Fax 561.297.0222

 [image] <https://hpc.fau.edu/wp-content/uploads/2015/01/image.jpg>

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Tom Scavo <trscavo at gmail.com>
Sent: Tuesday, August 22, 2017 10:36:26 AM
To: Shib Users
Subject: Re: Integrating idp3 with cirqlive

On Mon, Aug 21, 2017 at 9:54 PM, Joseph Fischetti
<Joseph.Fischetti at marist.edu> wrote:
> I've been asked to look into integrating cirqlive with our existing IDP 3
> installation. Cirqlive adds a link between Sakai and webex sso.

Apparently that "link" you speak of is not SAML Web Browser SSO since
CirQlive MEETS is not browser-facing (according to the document you
sent).

> During my
> research I found that cirqlive expects the private key of our IDP so that it
> can sign the assertions that it sends to WebEx.

No rational IdP operator would do that...

> Obvious security concerns aside, when I reached out to cirqlive for
> clarification, I received the following PDF in reply.  It seems that, given
> architecture 1 (page 3), they feel that sharing the idp's private key is
> okay.

Well then they don't understand how SAML works. If they possess a copy
of your private SAML signing key, they could impersonate your IdP at
will. Such a key must be considered compromised.

> They also reference using separate keys for different SPs, which as
> far as im aware, isn't possible with IDP 3.

I don't know about that but for the sake of argument let's suppose
that's possible. You can't publish the corresponding public key
certificate in federation metadata since then you're right back where
you started (i.e., complete compromise). So maintenance of that key is
necessarily out-of-band. For a compromised key, that's bad news.

That's actually the least of your worries. Assuming the private key is
securely transmitted to the 3rd party in the first place, that signing
key is still compromised since the 3rd party can impersonate any of
your users logging into webex. Worse, if they lose control of the
private key, you're right back where you started...complete and utter
compromise.

> Does anybody else have experience with this?

I hope not ;-)

Tom
--
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/20170822/ecb30e4b/attachment-0001.html>