Авторизация клиента ASP.NET WebAPI в распределенном приложении

Я создаю распределенное приложение, которое будет использовать веб-API ASP.NET для поддержки одностраничного веб-приложения (SPA) и других потенциальных мобильных платформ для мобильных приложений. Моя текущая архитектура использует Thinktecture Identity Server как STS, которая будет предоставлять токены авторизации для моих клиентов для доступа к WebAPI. В бэкэнд у меня будет постоянство и бизнес-логика, которые будут отображаться службой WCF в отдельном домене приложения из моего WebAPI. WebAPI вызовет уровень сервиса для доступа к данным и выполнения действий в домене.Авторизация клиента ASP.NET WebAPI в распределенном приложении

Мой вопрос примерно о разрешении. Я буду использовать авторизацию на основе требований и могу расширить список претензий из данных домена, хранящихся на пользователе, из моего бизнес-уровня, открытого для WCF. Но где я должен выполнять авторизацию? С .NET 4.5 ASP.NET теперь имеет расширяемую модель, позволяющую мне отделить логику авторизации от моих контроллеров в отдельный модуль авторизации - с помощью ClaimsAuthorizationManager. Кроме того, Thinktecture.IdentityModel делает действительно хорошую работу по предоставлению всей сантехники для этого в моем приложении WebAPI. Однако я не могу не думать о том, что логика авторизации должна находиться в моем бизнес-слое, за WCF-сервисом, и что для клиента, обращенного к клиенту, не должно быть поручено обеспечить его выполнение. Должен ли я требовать от других клиентов, стоящих перед размещенными приложениями, использовать мой бизнес-уровень на основе WCF, тогда им также потребуется внедрить защитный код. С другой стороны, это означает, что несанкционированный запрос довольно далеко проникает в приложение до его отклонения.

Вопрос: Должен ли я использовать возможности авторизации на основе претензий в ASP.NET или я должен обернуть авторизацию вокруг своего бизнес-уровня за WCF-сервисом?

источник

2013-09-30 jcaddy

Если вы будете получать доступ к своим услугам только через веб-сайт asp.net, вам будет проще иметь авторизацию дескриптора asp.net, чтобы избежать запросов на обслуживание. И если вы будете получать доступ к своим услугам другими потребителями, я считаю, что это будет более солидно, так как ваши службы обрабатывают авторизацию. – Esteban

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

Утверждение на основе утверждений является одним из многих подходов к авторизации. Другим было бы использование XACML. Недавно я поговорил о XACML для разработчиков (хотя разработчики Java). Вы можете узнать больше об этом here. Я также написал статью о .NET и XACML, которую вы можете проверить here.

источник

2013-10-01 16:42:39

Да, я абсолютно согласен с тем, что я должен использовать инструменты framework, а .Net 4.5 с MVC поможет мне изолировать логику. Это важно, поскольку моя логика авторизации будет очень мелкой. Сохранение этой сложности в одном месте минимизирует зависимость и облегчает обслуживание. Я беспокоился о том, где в архитектуре он должен сидеть. @Esteban Я догадываюсь, что это переделало проблему - все сводится к тому, как я хочу расширить систему в будущем - если это будет ** когда-либо ** будет WebAPI, то почему бы не использовать WebAPI Authz. Я думаю, XAMCL обращается к этому, разделяя проблемы. – jcaddy

. К вашему первому пункту, вот ссылка Microsoft, в которой объясняется, как использовать авторизацию на основе утверждений: http://msdn.microsoft.com/en-us/library/hh291068.aspx –

Авторизация клиента ASP.NET WebAPI в распределенном приложении

ответ

Смежные вопросы