SSO from Windchill to ThingWorx to REST API

[skongathi]

We are trying to perform something like this

1. Flex/Windchill and ThingWorx are installed in Lab on 2 Servers
2. Thingworx is configured to have Windchill as Authentication Service (With Windchill Extension), so SSO works when navigating from Windchill to Thingworx, in case a user is not there, TW creates it as logins-in
   1. a.       e.g. sourcing_user_1 from Windchill navigates to TW, a user with same name is created and logged in without asking for password.
3. SSO is working fine for thingworx with windchill.
4. Now , we a 3^rd Party app which uses REST calls from TW to access data from TW + Windchill
5. I need to achieve a seamless login (or SSO) from TW to REST API – which I am not able to
6. TW REST API can only accept Base64 – Basic Auth for REST API authentication, but we can never have password as we are only getting username as SSO from Windchill, this is tricky situation

Ideas is to achieve some kind of seamless auth from Windchill à TW à REST API (App)

Any ideas will help, please ask me if the description is not clear

[tbraun]

Hi,

is there an update on this issue? I also need a solution for making REST call possible from client via ThingWorx to Windchill.

Best Regards,

Tobias

[wposner-2]

Can you get away with using an appKey?  You can issue REST calls via a specific user in TWX that has been associated with the app key.  The main issue with this approach is that anyone making the REST call, does it using the same TWX user account. 

You could build some logic in to each of your REST API calls so that in addition to the appKey, you have to specify a username parameter and then evaluate the username against that user's actual group/org permissions prior to executing the real logic in your service. 

So for example, let's say you have a thing with a service that queries data from WC.  You would create a new REST API thing with a service that will ultimately call the WC query service.  The appkey would have permissions to execute services on your REST API thing.  Your service on that thing would take your query input parameters along with a username param.  You would then check to see if that username has permissions to call the WC query service on your other thing.  If the user is authorized, then simply call that service (you would also need to ensure the System user has access to the WC query service).  If the user is not authorized, then you throw an exception which gets returned back to the REST client.