Поток, инициированный IdP - определение учетной записи Okta

У меня есть приложение MVC (.Net Framework 4.5), которое было там в течение последних трех лет и использует механизм проверки подлинности с помощью форм. Это приложение предоставляет различные учетные записи, такие как Личная, бесплатная, корпоративная и т. Д. Для корпоративной учетной записи мы обрабатываем все в одном приложении. Т.е. предположим, что предприятие с именем "xyz" создало корпоративную учетную запись с приложением, затем мы предоставляем настраиваемый URL-адрес, например " https://application/xyz/login", и из URL-адреса, который мы идентифицируем, это предприятие. Я не знаю точной причины, по которой они реализованы таким образом, поскольку я видел, что приложения, имеющие корпоративные учетные записи, создаются в виде поддоменов (например, https://xyz.okta.com/). Теперь клиент попросил интегрировать Okta в это приложение. Поэтому я заглянул в Okta и обнаружил, что SAML - это правильный путь, и в итоге он оказался в KentorIT Authservices. Сначала я смог интегрировать это с примером приложения MVC, и часть аутентификации работала нормально. Имея некоторую базовую идею о едином входе, я начал интегрировать средства аутентификации kentor в свое приложение. Проблемы, которые я нашел в этой реализации:

1) Для учетных записей Enterprise параметры конфигурации Okta различны для каждого предприятия, и в моей текущей реализации приложения его невозможно установить из файла web.config. Поэтому я попытался установить его из кода, и мне удалось объединить эти параметры, заменив Configuration.Options.FromConfiguration;. Я планирую сохранить все данные, связанные с конфигурацией (URL-адрес единого входа, URI аудитории, издателя Identity Provider "и т. Д.), Чтобы я мог получать информацию в любое время, и я предполагаю, что" Identity Provider Issuer Идентификатор уникален для каждой учетной записи Okta. В потоке, инициированном IdP, когда пользователь пытается получить доступ к приложению, он перенаправляет на метод действия AuthServices\Acs, и с этого я пытаюсь прочитать параметры конфигурации. Из запроса есть В любом случае, я могу определить, откуда поступил вызов учетной записи Okta (например, Identity Provider Issuer)? В настоящее время я устанавливаю значение "Identity Provider Issuer" (и я думаю, что оно должно быть уникальным для учетной записи okta) в поле RelayState по умолчанию в общих настройках SAML вкладку, и я смог получить его из методов действия AuthServices\Acs. Кажется, это хорошая идея? Пожалуйста, совет.

2) Корпоративные учетные записи ограничены в зависимости от количества лицензий (скажем, 50). Предположим, что если администратор Enterprise Okta намеренно добавил 55 пользователей, все эти пользователи могут успешно аутентифицировать приложение на основе настроек по умолчанию. Есть ли способ, которым я могу справиться с этим сценарием. Нужно ли вести учет списка пользователей, которые попали под конкретную корпоративную учетную запись?

3) Из документов я понимаю, что служба аутентификации Kentor предназначена только для аутентификации, а авторизация должна выполняться из самого приложения. Текущая реализация приложения состоит из настраиваемого атрибута авторизации, который проверяет разрешения пользователей, которые хранятся в базе данных. Это должно быть там, как есть, и мы должны сделать авторизацию на основе разрешений базы данных. Правильно?

Жду ваших ценных предложений и поправьте меня, если я ошибаюсь. Заранее спасибо.

Источник

1 ответ

Решение

  1. Не используйте RelayState для конфиденциальных данных, если только вы не криптографически подписали их. Он не защищен никакой подписью при использовании привязки POST, поэтому пользователь может манипулировать ею. Чтобы получить выдавший idp, проверьте поле эмитента любой заявки, сгенерированной AuthServices.

  2. Да.

  3. Да, вот и вся идея с Kentor.AuthServies: подключить аутентификацию SAML2 к модели безопасности.NET, чтобы позволить вам использовать любые текущие / традиционные настройки авторизации.

Источник
Другие вопросы по тегам