Передать аргумент от поставщика удостоверений обратно проверяющей стороне после входа в WSFed

Есть ли способ передать значение проверяющей стороне после входа в систему? например на querystring?

Предыстория:

Что мы хотим сделать, так это сообщить проверяющей стороне, какое действие предпринял пользователь, например. войдите в систему или зарегистрируйтесь, чтобы проверяющая сторона могла отобразить пользователю соответствующее подтверждающее сообщение. Поскольку проверяющая сторона может ссылаться на страницу регистрации, но затем вместо регистрации пользователь входит в систему, поэтому проверяющая сторона не должна отображать панель уведомлений «Спасибо, что присоединились к нам».

Я попытался добавить &lastaction=signup к returnUrl, но это теряется, когда форма публикуется через Azure ACS.

Следующая попытка состояла в том, чтобы попытаться добавить lastaction к wreply, например:

WSFederationMessage message;
WSFederationMessage.TryCreateFromUri(uri, out message);
var signinMessage = wsFederationMessage as SignInRequestMessage;
if (signinMessage != null)
{    
    signinMessage.Reply += "?lastaction=hello";
    ...

В Fiddler я вижу, что следующий POST для ACS отправляется на https://xxxxx.accesscontrol.windows.net/v2/wsfederation?lastaction=hello Но lastaction не передается моей проверяющей стороне.


acs ws-federation
person Matt Frear    schedule 17.03.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

У нас была связанная проблема: мы хотели сообщить RP, какие методы аутентификации использовал пользователь при входе в систему. Мы решили эту проблему, создав новое «системное» утверждение с нашим пространством имен и поместив туда информацию.

В нашей реализации TokenService в методе AddSecurityClaims:

 claimsIdentity.AddClaim(
            new Claim(
                String.Format("{0}/{1}", WellKnownConfiguration.TokenService.ClaimsNamespace,
                    ClaimsAuthenticationMethods), ((int) userAuthenticationMethods)));

Обновление. Вы упомянули, что думали об использовании файлов cookie. В таком случае я бы сделал следующее. Я бы реализовал настройку файла cookie (например, на странице регистрации), а затем создал еще одно «действие», которое вернуло бы значение этого файла cookie. Когда приложение получает запрос POST с учетными данными, вы выполняете перенаправление (немедленно) на это действие ретрансляции с обратным URL-адресом. Затем это действие добавит значение файла cookie и вызовет исходный RP, но пользовательское действие, которое затем правильно отобразит представление.

Думайте об этом как о прокси-сервере cookie. Подводя итог, процесс выглядит следующим образом:

  1. Пользователь нажимает RP, действие требует аутентификации
  2. RP перенаправляет пользователя на STS в соответствии с WS-Federation.
  3. STS выдает токен, а также добавляет куки в собственный домен
  4. RP получает аутентифицированного пользователя, перенаправляет на STS Cookie Reader
  5. STS перенаправляет на второй экран RP, который может правильно обрабатывать вход в систему

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

person Anže Vodovnik    schedule 11.04.2014
comment
Спасибо. Мы также рассматривали возможность использования претензии или файла cookie, но у каждого из них есть свои проблемы. Утверждение слишком постоянное, и файл cookie нельзя использовать в разных доменах. - person Matt Frear; 11.04.2014
comment
Если заявка слишком настойчива, вы все равно можете использовать файл cookie в разных доменах. В этом случае я бы создал отдельный URL-адрес, на который приложение отправит запрос, чтобы получить его обратно. Это еще один прыжок, но он может быть достаточно быстрым, чтобы пользователь даже не заметил. Я обновлю ответ, чтобы объяснить. - person Anže Vodovnik; 11.04.2014