2016-06-30 4 views
0

Я ищу варианты реализации различных методов аутентификации в приложении SAAS. Приложение saas - это единственный экземпляр, который обслуживает всех арендаторов.Труба Owin на одного арендатора

Чтобы разрешить различные методы проверки подлинности, я мог бы создавать различные конвейеры owin для арендаторов, чтобы зацикливать все конфигурации арендаторов при запуске. Смотрите ответ нижний ответ здесь для объяснения: Change OWIN Auth Middleware Per Request (Multi-tenant, oauth API keys per tenant)

Я понимаю, что любые изменения конфигурации трубопровода заставит меня восстановить его, но я нашел хороший репозиторий, который, кажется, делает трюк. https://github.com/damianh/DynamicKatanaPipeline

Хотя решение о создании различных трубопроводов на одного арендатора возможно, я беспокоюсь об этом, не очень хорошо масштабируя. Мне было интересно, если это хорошее решение и знает ли кто-нибудь о подводных камнях, которые я не вижу с этим решением, или у меня есть опыт установки.

ответ

0

Основываясь на моем опыте работы с приложениями SaaS, я не вижу необходимости иметь отдельный трубопровод для каждого арендатора. Средство проверки подлинности должно быть достаточно умным, чтобы получить правильный идентификатор арендатора на основе предоставленной информации аутентификации.

После того, как удостоверение установлено, остальная часть приложения позаботится о процессе предоставления данных запросу на основе идентифицированного контекста.

НТН

0

У меня есть проект OWIN.Framework, что среди прочего позволяет быть более гибким, о строительстве трубопровода Owin, в том числе наличия нескольких путей через трубопровод для различных типов запроса.

Вы можете использовать это для настройки различного промежуточного уровня аутентификации для каждого арендатора, но другие части трубопровода будут одинаковыми для всех арендаторов.

Дайте мне знать, если вы заинтересованы и хотите помочь начать работу.