CWMS 1.5 - SSO/SAML With ADFS 2.0 - How I did it.

Unanswered Question
Nov 6th, 2013
User Badges:

All,


I have successfully configured SSO/SAML with full integration to Microsoft ADFS 2.0 to include not just authentication, but account details such as address, phone numbers, etc.  It was incredibly frustrating to find information detailing how to perform the tasks I needed, and also the errors in Cisco's documentation didn't help much.


Here are my findings:


  1. This guide here was a great start to get you basic SSO/SAML connectivity (All credit goes to Steve for posting this):  http://steve.heyvan.com/2013/04/06/connecting-cwms-to-adfs-2-0/
  2. The outgoing claim types ARE case sensitive.
  3. The claims rules that Steve posted will work, but can be simplified to a single rule as follows (including the user's address information):

    Main Account Details Rule.png
  4. Some clarifications for the screenshot: 
    1. The sixth LDAP Attribute is a lower case "L".
    2. Cisco Incorrectly listed the SAML assertion for zipcode as "ZIP Code" in their documentation.  The correct SAML assertion (or as Microsoft ADFS calls it, an Outgoing Claim Type) is ZipCode (case sensitive).
  5. For a list of other assertions see: http://www.cisco.com/en/US/docs/collaboration/CWMS/1_5/Planning_Guide_chapter_01001.html#reference_CD7A7E58EAF44AA4BBDCF67F5742ABF1
  6. Use SAML Tracer 0.2 for Firefox to see the contents of the SAML Assertion that you are sending to CWMS to assure that the data going over looks properly.  This was a huge help in verifying that everything was being transmitted.
  7. CWMS will not import any data into the user's account setting until the A/D account gets a new "whenChanged" value.  If you want to test, you might need to modify your test A/D account to change the "whenChanged" value so that the update will proceed.
  8. Getting phone numbers over to CWMS is a little more difficult, and you end up having to add 5 more custom claim rules in ADFS per phone number.  Simply add the following custom claim rules into ADFS for the Relying Party Trust that you created per Steve's blog (order of rules are important, you need to extract, then transform, then send. You can send in any order.  Schema.company.com type name doesn't really matter, but needs to match between rules):

1) Extract Office Phone Number:

(This rule grabs the telephoneNumber AD attribute and places it into ophone)

               ---- CUT HERE ----

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

=> add(store = "Active Directory", types = ("http://schemas.company.com/ophone"), query = ";telephoneNumber;{0}", param = c.Value);


               2) Transform Office Phone Number:

               (This rule takes the ophone variable and removes all non-digit characters and places it into ophoneplain)

               ---- CUT HERE ----

               c:[Type == "http://schemas.company.com/ophone"]

                => add(Type = "http://schemas.company.com/ophoneplain", Value = RegExReplace(c.Value, "\D", ""));


               3) Send Office Country Code:

               (We hard-coded country code to be US, Don't add the "+" sign in here, no first line, just a "=> issue" statement)

               ---- CUT HERE ----

                => issue(Type = "OPhoneCountry", Value = "1");


               4) Send Office Area Code:

               (Removes the right 7 digits from the plain phone number keeping area code only, modify {7} for your locale as needed)

               ---- CUT HERE ----

               c:[Type == "http://schemas.company.com/ophoneplain"]

                => issue(Type = "OPhoneArea", Value = RegExReplace(c.Value, "\d{7}$", ""));


               5) Send Office Local Phone Number:

               (Removes left 3 digits from the plain phone number keeping local number only, modify {3} for your locale as needed)

               ---- CUT HERE ----

               c:[Type == "http://schemas.company.com/ophoneplain"]

               => issue(Type = "OPhoneLocal", Value = RegExReplace(c.Value, "^\d{3}", ""));


               6) Repeat for mobile phone number (Comments omitted):


               Extract Mobile Phone Number:

               c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

                => add(store = "Active Directory", types = ("http://schemas.company.com/mphone"), query = ";telephoneNumber;{0}", param = c.Value);


               Transform Mobile Phone Number:

               c:[Type == "http://schemas.company.com/mphone"]

                => add(Type = "http://schemas.company.com/mphoneplain", Value = RegExReplace(c.Value, "\D", ""));


               Send Mobile Country Code:

                => issue(Type = "MPhoneCountry", Value = "+1");


               Send Mobile Area Code:

               c:[Type == "http://schemas.company.com/mphoneplain"]

                => issue(Type = "MPhoneArea", Value = RegExReplace(c.Value, "\d{7}$", ""));


               Send Mobile Local Phone Number

               c:[Type == "http://schemas.company.com/mphoneplain"]

                => issue(Type = "MPhoneLocal", Value = RegExReplace(c.Value, "^\d{3}", ""));



I hope this helps someone out there.  I know I could have used this a week ago.


-Pete

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joshua Warcop Fri, 02/07/2014 - 14:24
User Badges:

Thanks - looking to add SAML/SSO across several other UC applications and this is good starting point.

Emerson Telan Wed, 02/12/2014 - 18:55
User Badges:

HI Pkarelis,


Great to hear that! by the way, hows your authentication when you join the meeting? Does it goes directly to the meeting conference without any pop up?

I have mine setup but it gives me lots of pop up window. Hope I can hear it from you soon.


Thanks!



pkarelis Wed, 02/12/2014 - 19:02
User Badges:

We simply go to our meeting URL, and then click the "Sign In" button, and get directed straight to the meeting with Windows pass-through authentication (no pop-ups).


The trick is to change the authentication settings within IIS on the ADFS 2.0 server.  Within IIS manager, go to the adfs/ls directory and click on authentication, and make sure that Windows Authentication is enabled.


If your desktops are configured to pass-through credentials to intranet hosts, then it should work.

Emerson Telan Wed, 02/12/2014 - 21:05
User Badges:

Hi Pkarelis,


Thanks, I thought you are using the Outlook invite to launch the webex meeting. I want to achieve a single click only (just like how the "meet now" button works).

Once you click the URL, it should directly connect you to webex meeting without going thru the "sign in" button anymore.


Thanks!

gdsouza8484 Mon, 10/27/2014 - 21:30
User Badges:

Great guide, I followed it and got ADFS working in CWMS 2.0, but it has broken since upgrading to 2.5. have you tested CWMS 2.5 yet and were there any changes needed?

Emerson Telan Mon, 10/27/2014 - 22:05
User Badges:

Hi gdsouza8484,

 

How does your SSO behavior works. Does it work like once you click your WebEx meeting URL invitation does it go straight to the WebEx meeting?

 

Thanks!

pkarelis Tue, 10/28/2014 - 12:51
User Badges:

We haven't upgraded or even tested CWMS2.5.  It may be that there are additional SAML Assertions that it requires, or they have fixed the assertion for "ZIP Code", so that it is now "ZIP Code" as the documentation states, instead of "zipcode" that it was accepting before.

gdsouza8484 Tue, 10/28/2014 - 15:50
User Badges:

We are just sending the basics in the claim rule, Only email address, first name and last name. I have even turned of the auto creation for troubleshooting.

gdsouza8484 Tue, 10/28/2014 - 18:32
User Badges:

Here are the adfs claim rules that were working with 2.0, are there any new values that are now required. Can you send me a link to document that has the expected values?

Attachment: 
topher1086 Fri, 11/14/2014 - 11:40
User Badges:

I'm also seeing the same issue in our test environment.  I upgraded that from 2.0 to 2.5 and am getting an SSO protocol error when logging in.  Something has to be different, but I can't seem to figure it out either.  Any help would be appreciated.

topher1086 Thu, 12/18/2014 - 05:57
User Badges:

We used the workaround.  All we had to do was change the signature algorithm on ADFS for the WebEx rule to use SHA-1 instead of SHA-256.  After changing that it worked fine.

Actions

This Discussion

Related Content