Why do we need UPA for rehydrating users in Sharepoint provider hosted app scenario?

Our on prem. SPS 2013 environment is configged to authenticate through ADFS against a third party IDP. We know nothing about these users, the returned SAML contains a role and based on this role we authorize user in SPS. This works great.

No we are investigating high-trust provider hosted apps (on prem, no azure acs). We have created a simple MVC, and configged it to use ADFS. Now if users are authenticated from SPS they can call the MVC and the ADFS token is reused. Works perfect. Only thing is that whenever we need to call Sharepoint code through the client objectmodel, we get a 401 and the ULS shows that SPS is not able to map the incoming user to a user in User Profile DB. Off course it can't because the user is not in UPA and cannot be in UPA beacuse the users are stored outside our domain and there is no way to sync these to our SPS environment. I read a couple of blogs about this issue and the all say that we ned to sync with the user repository to fill upa; but again that cannot be (suppose on of our IDP's was facebook...?)

The construction works if we use apponly security, but now we lose our SPS security. So my real question is, can we some how workaround User Profile service in the scenario, or at least without needing to sync these users.

Any help/guidance is much appreciated!

Sander



November 15th, 2013 5:24am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics