WebEx is a a cloud based "Software as a Service" offering. The WebEx brand is owned by Cisco Corporation. For companies that purchased ten or more "Hosting" slots they create a custom branded WebEx website for managing the "Hosting" slots.
A Hosting slot to WebEx is a signed in user who has the ability to schedule or initiate a WebEx session for the purpose of conducting Web based audio/video conferences over the Cisco WebEx cloud based conferencing system. Participants who join the meeting are not individually licensed but receive web browser delivered software download packages that enable their internet connected workstation to use any audio/video conferencing equipment that may be attached to participate in the web meeting.
Customers of WebEx often already have an authentication system such as Active Directory, and often use ADFS or an OASIS style SAML2 compatible Single Sign On service in order to avoid proliferation of account management issues and to allow members of their domain to remember only one set of logon credentials.
Shibboleth is a commonly used SAML complaint SSO.
This is an example with Shibboleth 2.4.2 on RHEL6 connected to a Windows 2008r2 Domain.
On the WebEx provided Mangement page for the Customer service site
After signing into the WebEx Management site you would begin by choosing the
SSO Configuration menu option.
Then proceed to Upload a PEM format X.509 copy of your Shibboleth IdP SSL Cert
Choose Federation Protocol: SAML 2.0
Choose SSO Profile: SP Initiated
Provide the Service provider Id for this WebEx website:
Provide the Identity provider Id for the Shibboleth website:
Provide the Customer facing Single Sign On (SSO) url:
Then [Export] the metadata based on the previous answers into an XML file and upload that to the Shibboleth server: Example > /opt/shibboleth-idp/metadata/webxshib.xml
Choose NameID format: Unspecified
Choose AuthnContextClassRef: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Provide the Customer facing Single Sign On (SSO) logout page:
Then press [Update] to save the settings.
On the Shibboleth server
The WebEx website needs to be added as a Service Provider to the Shibboleth relying-party file.
/opt/shibboleth-idp/conf/relying-party.xml
</rp:DefaultRelyingParty>
<rp:RelyingParty id="https://mywebex-service-site.webex.com"
provider="https://myshibboleth.site.com/idp/shibboleth"defaultSigningCredentialRef="IdPCredential" defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
provider="https://myshibboleth.site.com/idp/shibboleth"defaultSigningCredentialRef="IdPCredential" defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport">
Where id = "Service provider Id for the WebEx website"
Where provider = "Identity provider Id for the Shibboleth website"
In the same file the SP metadata file needs to be loaded on startup of the Shibboleth service.
<metadata:MetadataProvider id="WebExMD" xsi:type="metadata:ResourceBackedMetadataProvider"><metadata:MetadataResourcexsi:type="resource:FilesystemResource" file="/opt/shibboleth-idp/metadata/webxshib.xml"/>
</metadata:MetadataProvider>
</metadata:MetadataProvider>
/opt/shibboleth-idp/conf/attributes-resolver.xml
<!--
========================================== -->
<!-- WebEx Attribute Definitions -->
<!--
========================================== -->
<resolver:AttributeDefinition
xsi:type="Simple" id="uid"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="sAMAccountName">
<resolver:Dependency
ref="myLDAP"/>
<resolver:AttributeEncoder
xsi:type="enc:SAML2String" name="uid" nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"/>
<resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"/>
</resolver:AttributeDefinition>
<resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified"/>
</resolver:AttributeDefinition>
The attributes need to be released by an attribute filter policy in the attribute-filter policy file.
/opt/shibboleth-idp/conf/attribute-filter.xml
<!-- Release Webex
Attributes -->
<afp:AttributeFilterPolicy
id="releaseToWebEx">
<afp:PolicyRequirementRule
<basic:Rule
xsi:type="basic:AttributeRequesterString"
value="https://mywebex-service-site.webex.com" />
</afp:PolicyRequirementRule>
<afp:AttributeRule
attributeID="uid">
<afp:PermitValueRule
xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>
</afp:AttributeFilterPolicy>
Services need to be stopped and started to pick up the changes.
# service tomcat stop
# service tomcat start
And a Shibboleth / Active Directory user should attempt to login to the WebEx provided Service site
It will take them to their familar Shibboleth SSO logon page for authentication.
After authentication it will return them to the same WebEx Service Site and if their UID matches one created in the WebEx magement page for this site. They will be allowed to schedule or initiate a WebEx meeting and send out invitations.
Additional options can be enabled for autoprovisioning Shibboleth accounts in the WebEx site or tracking and updating account authorization versus accounts that have been enabled or disabled in the Shibboleth IdP and hence Active Directory. Which merely requires returning additional attributes.