UCCX: HTTP Triggered Applications and Authentication

[Anthony Holloway]

Symptoms

UCCX does not natively protect HTTP Triggers.

Diagnosis

I wanted to come up with a solution to handle HTTP cookie based authentication.

Solution

There is a zip file for this project attached to this article.  It was written on UCCX 12.5(1).

Before HTTP Authentication

After HTTP Authentication

[Bill Talley]

What a coincidence, sitting here updating my rudimentary http trigger application for prompt management capabilities using a similar process as you've outlined here.  The challenge I'm running into is there doesn't seem to be a way to assign API access to agents or supervisors, so although I can authenticate them via the http trigger and use their login info (for auditing purposes) to upload the new prompt, I've had to either embed the API user info in the script, or prompt the user to input the API user info to generate the API calls via REST.

It's just something self contained within UCCX that doesn't rely on external web servers or IT support staff.

Great write up.  Thanks for sharing @Anthony Holloway .

Edit - this isn't an attempt to hijack your excellent post. Just sharing an example of how the process you've outlined for securing an http trigger can be used.

[Anthony Holloway]

@Bill Talley 

No worries Bill.  I appreciate the conversation.  I came to the same conclusion as you, that the API would not be able to be used with the Agent nor Supervisor credentials.  This is actually why I do not store their credentials in the solution, and instead, opted to store the authenticated user object.  You could then use this user object in your repo steps like upload document, or, you could simply just check for its existence, and then on their behalf, auth to the API with a pair of admin creds.  Don't forget to hide your admin creds though!
https://community.cisco.com/t5/collaboration-voice-and-video/uccx-masking-passwords-in-scripts/ta-p/3137357

[korvanessen]

Hi Anthony,

This post is (still) awesome. I've used it for a webpage to change openingtimes and it works like a charm.

I may have found something which is not functioning in the script the way you intended, which is the option to allow users/supervisors/admins to login. In your script there is a comment: "Roles are combined with OR logc. Default is no authorization". However, if I put both "allow_administrators" and "allow_supervisors" with "true" into the input Mappings of the authentication script, only admins are able to login. As soon as I put ONLY "allow_supervisors", both admins and supervisors can login. I think I see where this fails (the part below), and you might be able to fix it in the zip file so others don't run into the issue. Or you can tell me I'm just doing it wrong and everything works perfect

Further, I did a small tweak as well to the cookie info set. I add the "is_administrator", "is_supervisor" and "is_agent" to the cookie. These options are also used as output mappings to the script where authentication is required. This make me able to show a specific page to admin/supervisor/agent users when they login. In my case, the admin can also set default settings where supervisors can only set the openingtimes for specific departments.

thanks again for this post, really nice!

Best regards,

Kor