2

I'm looking for a bit of best-practice advice from someone a bit more knowledgeable than me in the Federated Security area.

Our Scenario

We host a (subscription) webservice (WCF/Asp.Net/IIS). We also have a purely JavaScript component (widget) that our customers embed within their intranet applications. The widget calls the webservices for data so therefore we need the widget to make cross-domain requests from their domain to our domain.

The widget currently does this using a combination of JsonP and Script Tag Injection approach to Ajax. (Reason - a combination of the age of the widget and continuing support for older non-CORS browsers).

The Problem

All of our customers require a Single-SignOn so their users are not asked to login to the widget. We have achieved this in until now by issuing an ApiKey to a new user and asking them to enter that into the widget on first use, and a cookie is then created for use thereafter.

We need to integrate Federated Authentication into this scenario. The webservice (on our domain) is the Relying Party (RP) and the widget (hosted on the customer domain) is the Client. The Identity Provider and STS would also be on the customer domain.

From my research so far I think I can make the following statements:

  • This scenario requires an Active Federation approach. Passive Federation is never used when the RP is a webservice.
  • We need to add Federated endpoints to our WCF service to allow an Active client to call us supplying a Saml token.
  • Making our widget an Active client that communicates with the webservie directly is not possible. This would require the Widget to request identity and pass it onto the RP. This would be too much for a JavaScript only app.

Possible Solutions

  1. Is it actually up to the host page of the widget (aka. the customer's intranet application) to be the Client in the FedAuth scenario?
  2. We could provide a proxy that would be hosted in the customer domain and act as the Active Client for our webservices RP. The widget could then be unaware of any authentication.
  3. Are we missing something really obvious?

I would really appreciate a couple of words in comment on the above if you can help us out and can spare the time. I'd be happy to hear that my assertions are incorrect as well. All news is good news at this point...

Andy McCluggage
  • 37,618
  • 18
  • 59
  • 69

1 Answers1

1

We eventually found a workaround:

For customers who want Saml Authentication we host the widget component in our domain in a standalone webpage and they embed in their webpage using an iframe.

this approach achieves the appearance of widget integration within their site, although not as originally intended, and it allows us to leverage Passive authentication. The iframe behaves just like a normal browser in that respect and handles the handshake with the STS server.

This is less than ideal but we were unable to come up with anything better. It suits our customer's needs whilst maintaining security. That doesn't mean I have to like it though.

Andy McCluggage
  • 37,618
  • 18
  • 59
  • 69