SSO with CUCM 10.5 and ADFS 3.0

[mbaker33]

Hello,

We recently updated our CUCM/CUPS/CUC system to 10.5 in order to take advantage of the SSO capabilities that are now built in.  All of the documentation points to ADFS 2.0, and we have an ADFS 3.0 implementation.  I am trying to figure out if this is an issue with the Claims Rule code, or if CUCM simply doesn't support ADFS 3.0.  

We have gone through the following links:

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/administration/guide/10xcucsagx/10xcucsag112.html#32035

https://supportforums.cisco.com/video/12155556/cucm-10x-samlsso-adfs20

But we are having trouble configuring the Custom Claims Rule, we get the attached error.

The rule we are applying is as follows, but with actual server names:

"c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, Originallssuer = c.Originallssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:3.0:nameid-format: transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://adfsserver.domain.com/adfs/com/adfs/service/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "phoneservername.domain.com");"

[Mateusz Pagacz]

Mark,

Try removing external quotes. My test rule, albeit for AD FS 2.0, looks like this:

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

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer =

c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =

"urn:oasis:names:tc:SAML:2.0:nameid-format:transient",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] =

"http://dc.example.local/adfs/com/adfs/service/trust",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] =

"cucm.example.local");

-Mateusz

[mbaker33]

I had tried it without the Quotes before, but something with your formatting is different, because it worked after updating server information!!  Thank you very much Mateusz!

Edit:

I think I spoke too soon.  When running the SSO test, I get "Error while processing SAML Response." in the results window.  I can see that the login was successful on the ADFS server, however, it doesn't seem right on the CUCM server.  

Mark

[Joshua Warcop]

Mark,

I'm not sure if you got this worked out but this can be related to a different entityID being used with ADFS 3.0. The correct entityID can be found in the downloaded FederationMetadata.xml from your server https://adfs.domain.com/FederationMetadata/2007-06/FederationMetadata.xml

Open that XML file and copy the entityID "https://adfs.domain.com/adfs/services/trust" to the location in the custom claim rule for namequalifier.

Previous rules may look like "http://adfs.domain.com/adfs/com/adfs/service/trust”.

So the updated would look like this -

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

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer =

c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =

"urn:oasis:names:tc:SAML:2.0:nameid-format:transient",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] =

"https://adfs.domain.com/adfs/services/trust",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] =

"cucm.example.local");

[mbaker33]

I thought you were going to be the hero.  I checked and found that the line in question was indeed wrong.  I adjusted it, and it had no affect at all.  Back to the drawing board....

Edit:

Also, if I test it from the ADFS test site https://adfs.domain.com/adfs/ls/idpinitiatedsignon, I can sign into ADFS fine, but when signing into the CUCM service, I get "The re-direction url is not available in saml response." which seems like a CUCM issue, but I can't say 100%.

Thanks,

Mark

[Joshua Warcop]

That is still correct because signing into ADFS first and selecting the CUCM site will fail. You have to go to the CUCM web page and click the link from there.

Are you doing the "Run SSO Test" from the SAML SSO configuration page?

[mbaker33]

Yes, I am.  I assumed that was the case, and wasn't terribly concerned.  I received a response from TAC indicating he is seeing ‘SSO metadata test time out’ in the logs.  He sent me the steps to go through the SAML Single Sign-On Configuration, which I had been doing already.

I bumped the logging to debug level, and got the following error in the log:

2015-01-06 15:20:35,715 ERROR [http-bio-443-exec-236] authentication.SAMLAuthenticator - Error while processing saml responseInvalid Status code in Response.

com.sun.identity.saml2.common.SAML2Exception: Invalid Status code in Response.

at com.sun.identity.saml2.common.SAML2Utils.verifyResponse(SAML2Utils.java:418)

at com.sun.identity.saml2.profile.SPACSUtils.processResponse(SPACSUtils.java:1051)

at com.sun.identity.saml2.profile.SPACSUtils.processResponseForFedlet(SPACSUtils.java:2108)

at com.cisco.cpi.sso.saml.sp.security.authentication.SAMLAuthenticator.processResponse(SAMLAuthenticator.java:74)

at com.cisco.cpi.sso.saml.sp.security.authentication.SAMLAuthenticator.process(SAMLAuthenticator.java:58)

at com.cisco.cpi.sso.saml.sp.security.filter.SamlFilter.doFilter(SamlFilter.java:63)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)

at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:341)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)

at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:744)

[Joshua Warcop]

What browser are you using to sign into CUCM and is your browser automatically signing you into ADFS during the redirect?

[mbaker33]

I have tried IE, Chrome and Firefox and they all have the same behavior.  On initially attempts, I am prompted for credentials.  On each subsequent attempt, it caches the credentials unless I close out of the browser session and start a new one.

[Joshua Warcop]

Are you expecting it to prompt for credentials? If your machine is on the same domain as the ADFS server you shouldn't be getting a password prompt. That somewhat defeats the purpose of SSO if you have to enter credentials. If you're in IE make sure you have adfs.domain.com or your domain in your Local Intranet sites list. Chrome shouldn't be prompting you for credentials either if you're domain joined and you can reach a domain controller.

[mbaker33]

That is exactly what I was thinking, but wasn't 100% sure.  I am on the same domain (although, on different subnet), and should not be getting prompted.

Another thing I just noticed that seems odd...  Look at the attached image and see the arrow pointing out what seems to be an invalid URL?  I'm grasping at straws here....

Also, since adding the site to trusted sites, i no longer am prompted for credentials, it just fails.  I assume that's a step in the right direction.

[Joshua Warcop]

Interesting. Are you accessing your CUCM server via FQDN in your browser? Something like https://cucm1.domain.com and is your certificate valid?

[mbaker33]

We use an internal CA for the certificates, and it does not prompt for authenticity.  I've also added the FQDN of the CUCM to the intranet sites list.  No change thus far.

[Joshua Warcop]

Have you also checked the "spnamequalifer" in your custom claim rule? You can find the value needed here from your downloaded "SPMetadata.zip" file that you download from CUCM. Open the XML file for your node and make sure the entityID matches between that XML file and your custom claim.

[mbaker33]

I had checked the ADFS XML, but for some reason not the one coming from CUCM.  Verified they were the same just now (they were) tried again for kicks, no dice.

I'm not sure if it matters, but the actual servername is not ADFS, I created the ADFS name specifically for ADFS to use per best practice.  I'm wondering if that has something to do with it.  I just can't figure out where that would be.  But, then again, SAML works when using the TEST URL.