Working with Scopes
Resource servers (RS) use scopes to permit the exchange of data with service providers (SP) on behalf of an authenticated user who has access rights to the data. Scopes are configured in the resource server to identify the data that should be exposed. A scope must also be registered in the Central Authentication Service (CAS), as well as in any service providers that you want to access the data. When a scope is registered in all three applications (RP, CAS, and SP), then a user can authorize the SP to access their data in the RP on their behalf. The CAS authenticates the user and facilitates the trust relationship between the SP and RP. The RP transmits the data directly to the SP. Note that the data is not routed through the CAS. Instead, the role of the CAS is to provide access tokens that the SP and RP use to establish a trust relationship so they know that the user has been authenticated and that the other application has authorized access to data owned by the user.
ThingWorx participates in SSO delegated authorization as a service provider. Scopes for resource servers, that is, other SSO-enabled applications that ThingWorx requests data from, need to be registered in the ThingWorx Integration Connector or media entity configuration table for the mashup or application that displays or uses the data. For more information, see Creating Integration Connectors and Media Entities.
 |
Scope names registered in a ThingWorx Integration Connector or media entity must match scopes registered in the CAS. If a scope in ThingWorx is misspelled or it is not registered in the CAS, then the ThingWorx administrator is not authenticated by the CAS when they try to sign in to ThingWorx. For information about how to resolve this situation, see Troubleshooting Single Sign-On.
|
For more information, refer to the topic Managing Scopes in Delegated Authorization in the PTC Identity and Access Management Help Center.