[cisco-voip] Flexible JID / MRA

Mon Feb 27 11:38:45 EST 2017

This comes back to Cisco failing what I call the apple test. Give someone a piece of tech and watch what they try to do with it in the first couple of hours. If you can check the box to yes on all those things, then you got a winning product.

This goes to the whole UDS vs. LDAP. Customers want the same experience inside and outside the organization.

Dennis Heim | Emerging Technology Architect (Collaboration)
World Wide Technology, Inc. | +1 314-212-1814
[cid:image001.png at 01D10DD2.7FC81F90]<https://twitter.com/CollabSensei>
[cid:image002.png at 01D10DD2.7FC81F90]<xmpp:dennis.heim at wwt.com>[cid:image003.png at 01D10DD2.7FC81F90]<tel:+13142121814>[cid:image004.png at 01D10DD2.7FC81F90]<sip:dennis.heim at wwtatc.com>
"Worry less about who you might offend, and more about who you might inspire" -- Tim Allen
“When you have unlimited time, its easy” – Captain Chesley Sullenberger
“There is a fine line between Wrong and Visionary. Unfortunately, you have to be a visionary to see it." – Sheldon Cooper
“The greatest danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it.” -- Michelangelo Buonarroti
“We should transform the way we work” – Rowan Trollope
“If you’re not failing every now and again, it’s a sign you’re not doing anything very innovative” – Woody Allen

Click here to join me in my Collaboration Meeting Room<https://wwt.webex.com/meet/dennis.heim>

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Huff
Sent: Monday, February 27, 2017 10:28 AM
To: Nick <csvoip at googlemail.com>
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Flexible JID / MRA

It seems obvious to me (and apparently you) that it should work.

As I understand it FJID was more of an after thought and was intended to allow XMPP routing to an alternate alias in federated scenarios.

However, that's a bit like letting the cat out of the bag ... if your going to make it 'sort of' work. From a lay perspective, I would expect this to work right out of the gate (especially since it does through non proxy authentication i.e, internal).

Doesn't seem like this would be a difficult ask for the BUs involved ... seems like a couple of COP files maybe and it's off to the races. Although, not sure what the priorities are; all things 'Spark' considered :).

Thanks,

Ryan

On Feb 27, 2017, at 10:19 AM, Nick <csvoip at googlemail.com<mailto:csvoip at googlemail.com>> wrote:
Hi Ryan

Thanks for your reply, thats saved me a lot of time. I can't believe this is not supported. I'll log a case and get it added to the enhancement.

Regards

Nick

On 27 February 2017 at 12:14, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
I can confirm that FJID is not supported over MRA. There is a bug ID for an enhancement request. It's only got 10 case on it though so you might want to jump on that wagon ;) .... squeaky wheel gets the attention and all.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy33691/?reffering_site=dumpcr

If you enable the experimental menu (assuming your EXP version has that capability) and you look in the unified log of Exp-C during a MRA login attempt with FJID (you could see this in the normal event log but there is a lot more noise) you'll notice that Exp-C is doing the standard UDS Service Discovery and then asking about the UserID being attempted, to the host it found in the discovery.

CCM (assuming that is your UDS target) will only respond positively to requests for the actual UserID ... which of course, is not the user's FJID.

Either CCM/IMP would have to be modified to also be able to authenticate and identify users with the Directory URI OR, Expressway would have to have some sort of MRA alias authentication capability .... or a combination of both.

The solution I've come up with is for the user to login with FJID initially (internally), thereby caching the real UserID (which is subsequently pre-populated in future login attempts...assuming a recent client version). Then, whether MRA or not, the user is simply entering the password or using auto sign in.

On Feb 27, 2017, at 6:40 AM, Nick <csvoip at googlemail.com<mailto:csvoip at googlemail.com>> wrote:
Hi Ryan

Did you get this working, I have exactly the same issue, flexible JID works fine internally, when the service discovery is done, it presents the actual user id and password prompt, however when using MRA, it does its service discovery but prompts the email address and password field which it doesnt allow you to log in with, if you then change it to user id you can log in?

Anyone else come across this?

Regards

Nick

On 15 February 2017 at 18:15, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
Has anyone got Flexible JID to work via MRA for the Jabber client's INITIAL, registration? FJID is working fine internally for INITIAL registration (and then the bootstrap is cached with the actual user ID so after that, doesn't really matter).

J4W 11.8
Exp c/e 8.7.1
CUCM / imp 11.0.1
(No LDAP, all CCM locally managed end users)
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170227/ec71393a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 4226 bytes
Desc: image001.gif
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170227/ec71393a/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2017 bytes
Desc: image002.gif
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170227/ec71393a/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 2014 bytes
Desc: image003.gif
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170227/ec71393a/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.gif
Type: image/gif
Size: 1939 bytes
Desc: image004.gif
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170227/ec71393a/attachment-0003.gif>