Клиент на JavaScript, осъществяващ достъп до уеб услуга с обединено удостоверяване - кръстосано домейн

Търся малко съвети за най-добри практики от някой, който е малко по-осведомен от мен в областта на Федералната сигурност.

Нашият сценарий

Ние хостваме (абонаментна) уеб услуга (WCF/Asp.Net/IIS). Имаме и чисто JavaScript компонент (джаджа), който нашите клиенти вграждат в своите интранет приложения. Приспособлението извиква уеб услугите за данни, така че ние се нуждаем от приспособлението, за да правим междудомейн заявки от техния домейн към нашия домейн.

Понастоящем приспособлението прави това, като използва комбинация от JsonP и подход за инжектиране на маркери на скрипт към Ajax. (Причина - комбинация от възрастта на джаджата и продължаваща поддръжка за по-стари браузъри, които не са CORS).

Проблемът

Всички наши клиенти изискват Single-SignOn, така че техните потребители не трябва да влизат в джаджата. Постигнахме това досега, като издадохме ApiKey на нов потребител и го помолихме да го въведе в джаджата при първото използване, след което се създаде бисквитка за използване след това.

Трябва да интегрираме федеративно удостоверяване в този сценарий. Уеб услугата (в нашия домейн) е Доверяващата се страна (RP), а джаджата (хоствана в клиентския домейн) е Клиентът. Доставчикът на самоличност и STS също ще бъдат в клиентския домейн.

От моето проучване досега мисля, че мога да направя следните твърдения:

  • Този сценарий изисква подход на активна федерация. Пасивната федерация никога не се използва, когато RP е уеб услуга.
  • Трябва да добавим обединени крайни точки към нашата WCF услуга, за да позволим на активен клиент да ни се обади, като предостави Saml токен.
  • Не е възможно да направим нашата джаджа активен клиент, който комуникира директно с уеб сървъра. Това би изисквало Widget да поиска самоличност и да я предаде на RP. Това би било твърде много за приложение само с JavaScript.

Възможни решения

  1. Всъщност зависи ли от хост страницата на приспособлението (известен още като интранет приложението на клиента) да бъде клиент в сценария на FedAuth?
  2. Можем да предоставим прокси, което ще бъде хоствано в клиентския домейн и ще действа като активен клиент за нашите уеб услуги RP. Тогава джаджата може да не знае за никакво удостоверяване.
  3. Пропускаме ли нещо наистина очевидно?

Наистина ще съм благодарен за няколко думи в коментар за горното, ако можете да ни помогнете и да отделите време. Ще се радвам да чуя, че и моите твърдения са неверни. Всички новини са добри новини в този момент...


person Andy McCluggage    schedule 24.06.2013    source източник


Отговори (1)


В крайна сметка намерихме заобиколно решение:

За клиентите, които искат Saml Authentication, ние хостваме компонента на джаджа в нашия домейн в самостоятелна уеб страница и те се вграждат в своята уеб страница с помощта на iframe.

този подход постига появата на интеграция на джаджи в техния сайт, макар и не според първоначалното предназначение, и ни позволява да използваме пасивно удостоверяване. В това отношение iframe се държи точно като нормален браузър и обработва ръкостискането със STS сървъра.

Това не е идеално, но не успяхме да измислим нищо по-добро. Той отговаря на нуждите на нашите клиенти, като същевременно поддържа сигурност. Това обаче не означава, че трябва да го харесвам.

person Andy McCluggage    schedule 20.08.2013