Daniel_Grosso | 2020-09-10 14:52:58 UTC | #1
Hi there.
We are trying to to prepare ourselves for:
https://developer.mypurecloud.com/forum/t/permission-enforcement-notifications-api/7221
And for that, we want to replicate the "October 1st" behavior on our partner lab org and then test it and, if ok, apply it to the production org.
Our app subscribes, among others, v2.users.{id}.conversations. So, I went to our SAML2 Bearer oauth client and defined the scope as alerting:readonly.
It was my expectation that our app would not work anymore because, at least, we should have "users:readonly" in the scope. The app still works, meaning, i can still subscribe for everything. Am I thinking right here?
Furthermore, in the topic above is not quite clear if the permissions on Becky's table are to be set at the Oauth client scope or to the users roles.
Can someone please clarify?
Thank you.
Regards, Daniel Grosso
Becky_Powell | 2020-09-10 19:23:56 UTC | #2
Hi Daniel,
Thanks for reaching out. In fact, we have not begun enforcing these permissions, as we have gauged that the impact of this change would be too detrimental to consumers of our Notifications API.
We have identified the customers who would be impacted and have started outreach to ensure that they have their users have the appropriate permissions to subscribe to a given topic. Once we have completed that outreach, we will update the original announcement with a revised effective date.
To answer your second question - the permissions I referenced are user permissions.
Best, Becky
Daniel_Grosso | 2020-09-11 09:19:09 UTC | #3
Hello Becky
Thank you for replying.
I few more questions, if you please:
- Will our app break at October 1st if we do nothing?
- When will we be able to test this change in out PartnerLab
- Because we are using SAML auth the only permissions we should worry about are the ones from the users, am I right? If, so, why do I need to set scopes at the oauth client level?
Thanks again.
Regards, Daniel
tim.smith | 2020-09-14 16:04:25 UTC | #4
Daniel_Grosso, post:3, topic:8796
Will our app break at October 1st if we do nothing?
If your app lacks the required permissions, it will break when those missing permissions are enforced.
Daniel_Grosso, post:3, topic:8796
When will we be able to test this change in out PartnerLab
I don't know what that is, but if that's one of your orgs in production, the changes will be rolled out per the dates in the announcement.
Daniel_Grosso, post:3, topic:8796
Because we are using SAML auth the only permissions we should worry about are the ones from the users, am I right? If, so, why do I need to set scopes at the oauth client level?
The method of assigning permissions to roles and roles to users and client credentials is not changing. Users using notifications must have appropriate permissions assigned to them via roles. Client Credentials using notifications must also have appropriate permissions assigned to them via roles.
Daniel_Grosso | 2020-09-14 18:27:48 UTC | #5
Hello Tim.
I don't know what that is, but if that's one of your orgs in production, the changes will be rolled out per the dates in the announcement.
It's our DEV/TEST organization. We need to have enforcement applied first in this org so we can test the impact and the changes. We have discussed this "preview" need on another similar subject in a conference call a couple years ago (don't know if u remember).
The method of assigning permissions to roles and roles to users and client credentials is not changing. Users using notifications must have appropriate permissions assigned to them via roles. Client Credentials using notifications must also have appropriate permissions assigned to them via roles.
Got it. However, currently I have no scopes set in our SAML Oauth client but if I try to edit this client the scopes are considered mandatory. Since all requests are made on behalf of the users, why are scopes mandatory in SAML Oauth clients?
Thanks in advance
Regards, Daniel
tim.smith | 2020-09-14 18:49:11 UTC | #6
Daniel_Grosso, post:5, topic:8796
currently I have no scopes set in our SAML Oauth client but if I try to edit this client the scopes are considered mandatory.
Correct. Old OAuth clients predating the scopes feature are grandfathered in without scope enforcement, but they cannot be updated without conforming with mandatory scope configuration. More information about scopes can be found here:
tim.smith | 2020-09-14 19:39:53 UTC | #7
Daniel_Grosso, post:5, topic:8796
Since all requests are made on behalf of the users, why are scopes mandatory in SAML Oauth clients?
I wanted to add more context for this part. Scopes are required because they serve a different purpose than the user's permissions. In the context of OAuth, users and applications are separate entities.
A user has permission to various resources within Genesys Cloud. This controls what a human is allowed to do within the context of the Genesys Cloud service as a whole.
An OAuth client has scopes to control what the application is allowed to do and which resources it is authorized to use.
A user may have more permissions than an app needs, and an app may request more scopes than a user has permissions for. But the overlap of those two lists is what an authorization token authorizes an app to do. This creates the basis of trust between a user and a 3rd party app because scopes both restrict and advertise what the app has the ability to do.
Scopes in Genesys Cloud are the same concept as when you use Google or Facebook to log in to other services it prompts you with something like "this app can read your posts, post to your feed, etc." You, as a human, are allowed to post on facebook, but you may not want random apps you signed in to with facebook to be allowed to make posts as you.
Daniel_Grosso | 2020-09-15 08:34:40 UTC | #8
Hello Tim.
Thanks. It's more clear now. Just to be sure (because English is not my native language), by "overlap", you mean the intersection, right? So our users can have permissions to receive notifications of conversations but if the oauth client doesn't, it will fail, right?
What about the "preview" I mention earlier? Is it possible? I'm worried about this. We don't want our client to have its service disrupted, we may face penalties.
Regards, Daniel
system | 2020-10-16 08:34:42 UTC | #9
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 8796