Is there such a thing as a permission system for the finesse api?

[stephan.steiner]

Hi

Lacking information in the documentation I went on the way to try and figure out how permission work for the finesse api by trial & error.

The results are.. well, I can't find a pattern yet.

Here's what I found

If I configure any user as an agent, I can then use that user's credentials to extract some information.

here's what worked and what didn't (the user has no skills, is not a supervisor or has any other role other than being an agent)

This works:

• Extracting a given team if I know its I.
• Extracting the list of queues
• Extracting queues for any agent user if I know its userid (loginId)
• Extracting my own user object
• Extracting a list of dialogs of any agent user if I know its userid (loginId)

And here's what doesn't work

• Extracting a list of teams
• Extracting any agent other than the user whose credentials I'm using
• Extracting the user list

Does that make sense? I'd argue no.. imho generic list operations (users, teams, etc.) should be constrained. An admin should be able to do them all, a supervisor should be able to do it for their teams (where he's a supervisor.. for all teams depending on system configuration). Extracting lists below users (e.g. a user's queues, a user's dialog) should follow the same rule.

Clearly that's not the case.

I then proceeded to the notification interface that I'm accessing via XMPP. Note that the user is still only an agent, and is not part of any team or has any other role.

Here's what works

• Subscribing for user notifications for any user
• Subscribing for team notifications for any team
• Subscribing for dialog notifications for any user

Here's what doesn't work

• Nothing

Am I wrong to have expected some kind of permission system that has to do with a user's roles? e.g. I'd expect an admin to be able to do everything, a supervisor to be able to do operations that affect his team and team members, and a regular agent only being able to see himself.

[stephan.steiner]

And now I've tried with a user that is not an agent.

Here on XMPP nothing works.. trying to subscribe for any user just gets me an error 400. Same for user dialogs and teams.

However, as for the REST API, things present themselves in a mysterious way.

when I initially created the user a few hours ago, I immediately tried, first without assigning any rights. Of course, that got me 403 errors in every operation as expected. I then assigned the user admin rights, and expected it to work, but still got a 403 for all operations. Then I had to do other stuff for a few hours, and when I returned, I assigned supervisor rights (the user is not a supervisor in any team so far), and tried again, and lo behold, it worked. Then I tried removing the supervisor rights again, and it still worked, and then I removed the admin rights and it still worked and now I'm thoroughly confused. It almost seems as if rights get cached, and they only get applied after a certain time. I'm now rebooting the box to try again with a user that has zero rights. But of course, if it takes a while for rights to take, there's a good chance my findings will be corrupted because I have no idea when rights start to be applied.

[stephan.steiner]

In order to get to the bottom of this, I rebooted the server and ran the tests again. It started out as expected.. user with no roles means he cannot do anything. Then I assigned the admin role, and every REST API call I tried (I'm not trying to change agent status.. it's just reading information at the moment), worked. I then removed the admin role again, and operations keep working. Needless to say I restart my application in between tests so any cached credentials on my end of things are cleared.

[dekwan · Accepted solution]

Yes, there is such thing as a permissions system for the Finesse API.

Documentation for the REST APIs can be found at the Finesse DevNet

site: https://developer.cisco.com/site/finesse/ under

Guides->REST API Developer Guide

(https://developer.cisco.com/docs/finesse/#!rest-api-dev-guide).

In the developer guide, each REST API has a table. In the table, there

is a "Security Constraints"row. This will tell you which user role can

use that particular REST API.

For example, one of the items you mentioned in the forum is extracting

a list of teams. If you look at the List of Teams API here: https://developer.cisco.com/docs/finesse/#!teamget-list, the security constraints says "Only administrators can use this API."

As far as the XMPP events, take a look at the "Notifications Triggered:"section of the table. That will tell you which node events will be published to as a result of that REST API request.

[stephan.steiner]

Denise

What about my experience with adding/removing the admin role not immediately having an effect?

And, regarding XMPP.. why can I, logged in as an agent (logged in on xmpp), subscribe for agent state changes for any other agent? And conversely, I cannot even log in if I have a user that is not an agent? There must be a permission system for xmpp as well, no?

And what about making a user an admin? (see here: Making a user an admin and permission system). I realize it's not the Finesse API, but related anyway.

[dekwan]

Hi,

Assigning admin capabilities is not immediately reflected due to caching. It has been observed that UCCX does not update Finesse of this new role change and that restarting the "Cisco Finesse Tomcat" service is needed for the change to be reflected.

For XMPP, users that are not agents cannot log in because Finesse only creates users that are agents or supervisors. As far as an agent subscribing to another agent's events, I do not believe Finesse is very strict on that.

You would need to follow up on the UCCX forum for your question about making a user an admin.

Thanx,

Denise

[stephan.steiner]

I'd argue that the permission updates not being reflected immediately is a bug. From a security standpoint, removing a right, then being able to still do it.. that's a major violation.

And as for the lax XMPP permissions.. to my current setup it's an advantage because you can't use an admin (it's an unfortunate development that more and more APIs completely disregard the server to server approach.. one session per user really doesn't fly if you have large systems), due to the lack of admin monitoring capabilities, effectively you end up wasting one agent license just for monitoring when building a server to server app that needs notifications. My customer is going to love that news

[dekwan]

Finesse is meant to be an agent/supervisor desktop. The APIs/notifications are meant for this purpose too. Finesse isn't meant to be a monitoring tool, which is why you cannot use an admin to do these things. If you would like to get all of the events, then you would connect to UCCX/UCCE system itself.

[stephan.steiner]

Well.. comparing the socket based API (CTI Protocol for CCX) with an XMPP API is like comparing an 8086 with a core ix processor... the amount of sheer plumbing that goes into the implementation of the former is staggering, and you wouldn't want to deal with the oldtimer if there's a shiny new piece of equipment available.

Still.. if what you say is true, then monitoring other nodes should be tied to the supervisor right, should it not?

[dekwan]

I totally agree that using XMPP API is much newer and easier, which is why Finesse uses it!

There is a difference between a supervisor monitoring its own team (which Finesse has) vs monitoring ALL teams/agents. With UCCE/UCCX, the model has always been that the supervisors can monitor its own teams. So, Finesse is continuing to follow that model.

[stephan.steiner]

But, it doesn't fully follow that model.. you're not restricted to only monitoring other users by any supervisor role you may have.. you can be a normal agent and can monitor any other agent.

Again, not an issue for me (in fact given you seem to be unable to assign admin roles in any way, it's the only way to get working what I need to do), but if you look at it from a security standpoint, it's less than ideal.