Tom Greene – Paragon Development Systems, Inc.
Neil Cashell – Novell Technical Services
This goal of this document is to show how Novell Access Manager can be used to single sign on to Cisco’s WebEx collaboration cloud using the SAML2 protocol. Although we will be referencing SAML authentication requests and responses, and assertion specifics, details on the SAML protocol is outside the scope of this document. An outline of the configuration steps required on both the Novell Access Manager Identity server and WebEx server will be covered. We will also cover some basic troubleshooting in a separate section where we look at available tools and log files for troubleshooting SAML, as well as sample entries showing successful communications.
Before attempting this integration, you should:
The Cisco WebEx server is simply a SAML2 Service Provider (SP). It’s goal is to
In order to be able to do this, the Cisco WebEx server must know the type of SAML Authentication request required to authenticate to the IDP server, and what URLs to send it to on the IDP server. In the screenshot below (figure 1), the following options must be enabled and populated:
When the user has successfully authenticated to the SAML IDP server, an assertion is generated by that IDP server and sent to the WebEx service provider via the browser. The assertion generated by the IDP server is signed and the signature must be validated by the WebEx server. In order to validate the signature, the WebEx configuration must import the correct signing certificate (available from the NIDP-signing keystore on Access Manager). In figure 1, you will see the site certificate manager link in the upper left. Select that and import the Identity Server signing certificate.
Figure 1: Cisco WebEx SAML SSO configuration
Establish trust relationship between Novell Access Manager SAML2 Identity Server and the Cisco WebEx SAML2 Service Provider.
At the Novell Access Manager Admin Console, select the IDP configuration and go to the SAML2 TAB. Under Trusted provider, create a new SAML2 Service Provider. At the prompt, give this new SAML2 SP a logical name (WebEx below) and point to the WebEx SAML2 metadata that was exported from the WebEx SSO configuration page defined in figure 1.
NOTE: When exporting the metadata from WebEx and importing it into Access Manager, the certificate validation process would fail. Although the certificate is only required when Authentication requests from the WebEx SP are signed (and they were not), the exported metadata did not contain the proper certificate. Instead of including the server certificate in the metadata, the certificate referenced was the trusted root certificate.
To overcome the issue, and allow to future authentication requests to be signed, we modified the exported metadata to include the server certificate instead of the trusted root. We then exported the server certificates trusted root and imported into it into the NIDP truststore on Access Manager.
After importing the metadata successfully, make sure the Service provider is displayed as shown below in Figure 2.
Figure 2: WebEx SAML2 SP created on Novell Access Manager Administration Console
The WebEx SP requires the NameIdentifier format to be unspecified, and that it include as a value the username. In order to be able to send the username in the NameIdentifier header, one must define an attribute set with that username first.
By selecting the Identity Servers -> Shared Settings field in the Administration Console, one can create a new attribute set (called WebEx below in Figure 3) and include a list of attributes that may need to be sent to the WebEx SP from the IDP server. In our example, we included 4 LDAP attributes (cn, mail, givenName and sn) as examples. The only requirements are that the cn and mail be sent.
Figure 3: Attribute set configuration with attributes required by SP
Once the Attribute Set is defined and applied to the IDP server, the SAML configuration can leverage any of these attributes to send them with the assertion. By selecting the WebEx SAML2 SP configuration in the Admin Console again, the Administrator can go to the Attributes TAB and select the newly created WebEx attribute set from the drop down menu as shown in Figure 4. The LDAP attributes should be mapped to remote attribute names expected by WebEx SAML SP (uid, firstname, lastname and email in our example below).
Figure 4: Mapping Local Attributes to Remote Attributes.
By moving these attributes to the ‘Send with Authentication’ field (figure 5), the IDP will include an AttributeStatement for each of these attributes, along with their corresponding values.
Figure 5: Defining Attributes to send in Assertion.
More importantly, the Authentication response must be configured to send the ‘unspecified’ NameIdentifier format, with the authenticates users LDAP CN (requirement for WebEx SSO). In Figure 6 below, we make sure that the ‘unspecified’ NameIdentifier format is enabled, and that it is the default format used in the response. It’s value must also be set to include the username of the user that will be used to SSO to the WebEx SP.
The binding used must always be set to POST. WebEx does not support the Artifact based binding.
Figure 6: Configuring the Authentication response attributes that will be sent from the IDP server to the WebEx SP
As an aside, it is possible to configure the IDP initiated SSO between the Novell Identity Server and the WebEx SP. The ‘Intersite Transfer Service’ configuration TAB can be used to define the SP ID and target URL as shown in Figure 7.
In this scenario, the users do not have to browse to the WebEx SP first and then select to authenticate at the Novell IDP server … they can simply hit the base URL of the Novell IDP server with the following query, authenticate successfully at the IDP server and the user is redirected to the WebEx server where the SSO will take place: https://youridp.yourdomain.com/nidp/saml2/idpsend?id=WebEx
Figure 7: IDP initiated SSO setup using Intersite Transfer Service
The WebEx SP, based on the configuration in Figure 1, generates an Authentication request to the Novell IDP server with an authentication type of PasswordProtectedTransport.
The Novell Identity Server works with authentication contracts by default, and not authentication types. A mapping must be configured between the incoming authentication type (as shown in Figure 8), and the corresponding contract that must be executed to login the user. If no mapping exists, the default Authentication contract (also shown in Figure 8) is executed.
Selecting the IDP server configuration -> Local -> Defaults TAB, there is an option where the Administrator can map authentication types to contracts. The PasswordProtectedType (authentication over a secure channel) was mapped to the secure Name/Password Form contract, so that when the incoming Authentication request was processed, the IDP server simply executed the Secure Name/password form contract and presented the user with the login page. If the WebEx was configured for the Password type as opposed to PasswordProtecedTransport, we would map the password type to Name/Password form contract (authentication over an insecure channel) – although this is not recommended as credentials are passed in clear text.
Figure 8: Mapping Authentication types sent by SAML2 SP to authentication contracts understood by the Novell IDP server
The testing of the setup simply involves bringing up a browser and accessing your WebEx server, or application. Assuming that the setup is successful, the WebEx server should allow you to sign on via your newly created trust relationship with the Novell Identity server. In our example, the option to Sign in to Novell’s Identity Server is done by clicking the ‘Host Log In’ button on the main WebEx page as shown in Figure 9.
Figure 9 – Signing in to WebEx via Novell Identity server
Selecting the option to login, the WebEx server will generate the SAML authentication request to the Novell IDP server with the appropriate settings. This request is sent via the browser to the single sign on URL defined on the WebEx server and is encoded. It also includes a RelayState parameter that includes the URL the user was trying to access initially. This user will eventually be redirected back to this RelayState URL after successful authentication.
Figure 10 – Authentication request sent by WebEx SP server to Novell IDP server
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"ID="s2af73ec1bf438040c88f427ee82d9f1a43d55ae07" Version="2.0" IssueInstant="2011-08-18T15:33:23Z"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://yourcompany.webex.com</saml:Issuer> <samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true"></samlp:NameIDPolicy></samlp:AuthnRequest<samlp:RequestedAuthnContext Comparison="exact"><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></samlp:RequestedAuthnContext></samlp:AuthnRequest>
Assuming that the Novell IDP server is capable of validating the source of this Authentication request (based on finding a matching trusted provider in it’s SAML trusted provider configuration), the user will be prompted to login to the Novell Identity server (Figure 11). In our example, we have a simple non customized login page asking the user for name and password. This may be modified to ask for other credential details.
Figure 11 – Login page at Novell Identity server
After the user submits the credentials, the Identity server will validate them against the back end user store. It will also retrieve the users LDAP CN based on the attribute set defined for our SAML Authentication response. Assuming the IDP server has all it needs, it will generate the SAML authentication response to the WebEx SP server and single sign on the user. The resulting page will display the authenticated user (pds2 in our case) as logged in on the WebEx main page as shown in Figure 12.
Figure 12 – Successful single sign on to WebEx showing the admin username
The SAML assertion sent to the WebEx SP Assertion Consumer service includes the following details:
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://yourcompany.webex.com/dispatcher/SAML2AuthService?siteurl=yourcompany" ID="idrdSMbMXUCGl2LrjAJtwVbWG08H0" IssueInstant="2011-08-18T15:34:06Z" Version="2.0"> <saml:Issuer>https://youridp.yourdomain.com/nidp/saml2/metadata</saml:Issuer> <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status> <saml:Assertion ID="ideLWtTf2CmFXuNlbAlDtqFSgL-hE" IssueInstant="2011-08-18T15:34:06Z" Version="2.0"><saml:Issuer>https://youridp.yourdomain.com/nidp/saml2/metadata</saml:Issuer> <ds:Signature : Signature and certificate details : <saml:Subject><saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="https://youridp.yourdomain.com/nidp/saml2/metadata" SPNameQualifier="https://yourcompany.webex.com">youraccount</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData NotOnOrAfter="2011-08-18T16:34:06Z" Recipient="https://yourcompany.webex.com/dispatcher/SAML2AuthService?siteurl=yourcompany"/></saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2011-08-18T15:29:06Z" NotOnOrAfter="2011-08-18T15:39:06Z"><saml:AudienceRestriction><saml:Audience>https://yourcompany.webex.com</saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatement AuthnInstant="2011-08-18T15:34:06Z" SessionIndex="ideLWtTf2CmFXuNlbAlDtqFSgL-hE"><saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef><saml:AuthnContextDeclRef>secure/name/password/uri</saml:AuthnContextDeclRef></saml:AuthnContext></saml:AuthnStatement><saml:AttributeStatement><saml:Attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"><saml:AttributeValue xsi:type="xsd:string">**</saml:AttributeValue></saml:Attribute><saml:Attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"><saml:AttributeValue xsi:type="xsd:string">**</saml:AttributeValue></saml:Attribute><saml:Attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="lastname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"><saml:AttributeValue xsi:type="xsd:string">**</saml:AttributeValue></saml:Attribute><saml:Attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="firstname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"><saml:AttributeValue xsi:type="xsd:string">**</saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response>
Under the Subject header, we can see the NameID tag with the value of the authenticated users LDAP CN (yourname in our example). This is what the WebEx server will retrieve to authenticate the user. The additional attributes are used by the WebEx SP should the user not already exist and user provisioning is enabled.
Should any part of the above setup fail and require debugging, the troubleshooting process outlined in Troubleshooting SAML assertion issues can be followed. Although it is for a different setup, the process is identical and will help pinpoint the problem area.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.