Комментарии 55
Угу. Напишите, пожалуйста, как развернуть web-приложение с wif-аутентификацией стандартным webdeploy.
Сам процесс развертывания(обновления бинарников и тд.) ничем не отличается. Различия только в том, что после развертывания необходимо внести изменения в web.config(секция microsoft.identityModel). Если ваше приложение деплоится всегда на один хост, то можно использовать стандартные web.config transformations при сборке. Остальное зависит от того, как у вас устроен процесс аутентификации и авторизации, какие токены вы используете, какая политика в части X.509 сертификатов и тд. Все это тяжело уместить в одном посте :). Опишите сценарий, который вас интересует, чуточку поподробнее.
«Сам процесс развертывания(обновления бинарников и тд.) ничем не отличается.»
Правда? WIF Runtime на сервере разворачивать не надо?
Правда? WIF Runtime на сервере разворачивать не надо?
Опять же это зависит от конкретного сценария. WIF Runtime доступен через Web Platform Installer и его можно указать в пререквизитах, если ваше приложение деплоится через WebPI. Можно просто поставить Copy Local = True для Microsoft.IdentityModel, можно скачать отдельно и поставить или, если вы используете .Net 4.5, вообще ничего не нужно делать. К самому WebDeploy это явного отношения не имеет. Повторюсь, зависит от сценария.
«Опять же это зависит от конкретного сценария. WIF Runtime доступен через Web Platform Installer и его можно указать в пререквизитах, если ваше приложение деплоится через WebPI.»
Это не webdeploy.
«Можно просто поставить Copy Local = True для Microsoft.IdentityModel»
Не работает.
«можно скачать отдельно и поставить»
Через webdeploy?
«если вы используете .Net 4.5, вообще ничего не нужно делать»
Вот на это одна надежда. Когда он выйдет в продуктив, проверим.
Это не webdeploy.
«Можно просто поставить Copy Local = True для Microsoft.IdentityModel»
Не работает.
«можно скачать отдельно и поставить»
Через webdeploy?
«если вы используете .Net 4.5, вообще ничего не нужно делать»
Вот на это одна надежда. Когда он выйдет в продуктив, проверим.
«Это не webdeploy»
Он интегрирован туда.
Цитата: «The tool also integrates with the Web Platform Installer»
www.iis.net/download/webdeploy
Этот способ используется к примеру если вы свои приложения публикуете через свой собственный источник в WebPI.
«Можно просто поставить Copy Local = True для Microsoft.IdentityModel»
Не работает.
В наших приложениях используем просто Copy Local для сборки. Проблем не наблюдается.
Так же явно указано что WIF Runtime можно поставлять с приложением не требуя явной установки.
social.technet.microsoft.com/wiki/contents/articles/1898.aspx#Q11
«можно скачать отдельно и поставить»
Через webdeploy?
Может я вас не полностью понимаю, но вопрос установки WIF и процесс WebDeploy не связаны между собой каким-то явным способом.
Опишите ваш сценарий развертывания, и можно будет это обсудить :)
Он интегрирован туда.
Цитата: «The tool also integrates with the Web Platform Installer»
www.iis.net/download/webdeploy
Этот способ используется к примеру если вы свои приложения публикуете через свой собственный источник в WebPI.
«Можно просто поставить Copy Local = True для Microsoft.IdentityModel»
Не работает.
В наших приложениях используем просто Copy Local для сборки. Проблем не наблюдается.
Так же явно указано что WIF Runtime можно поставлять с приложением не требуя явной установки.
social.technet.microsoft.com/wiki/contents/articles/1898.aspx#Q11
«можно скачать отдельно и поставить»
Через webdeploy?
Может я вас не полностью понимаю, но вопрос установки WIF и процесс WebDeploy не связаны между собой каким-то явным способом.
Опишите ваш сценарий развертывания, и можно будет это обсудить :)
«Он интегрирован туда.
Цитата: «The tool also integrates with the Web Platform Installer»
www.iis.net/download/webdeploy
Этот способ используется к примеру если вы свои приложения публикуете через свой собственный источник в WebPI.»
Вы путаете. WebDeploy входит в WebPI, т.е. можно поставить WebDeploy из WebPI, но не наоборот. Процесс выкатки приложений с помощью WebDeploy c WebPI не связан.
«В наших приложениях используем просто Copy Local для сборки.»
Web или Win? Какой целевой фреймворк? Как настроен сервер?
«Проблем не наблюдается. Так же явно указано что WIF Runtime можно поставлять с приложением не требуя явной установки. social.technet.microsoft.com/wiki/contents/articles/1898.aspx#Q11»
Эээ? Вы об этом?
«Q: My application uses WIF and requires that it be installed as a prerequisite. Can I distribute the runtime files with my application?
A: Absolutely. There is now an additional EULA for the WIF SDK that allows developers to redistribute the WIF runtime with their application when they develop an application using WIF.»
Тут написано, что можно распространять, но не написано, что работает bin deploy.
«Может я вас не полностью понимаю, но вопрос установки WIF и процесс WebDeploy не связаны между собой каким-то явным способом.»
Зато связаны процесс развертывания web-приложения, использующего wif.
«Опишите ваш сценарий развертывания, и можно будет это обсудить»
У нас есть web-приложение, использующее WIF. Когда мы хотим развернуть его на новый, из коробочки Windows Server, сколько всего нам надо туда поставить?
На данный момент мы не нашли способа это сделать (развернуть его на чистый сервер), не ставя туда WIF Runtime через соответствующий msu.
Цитата: «The tool also integrates with the Web Platform Installer»
www.iis.net/download/webdeploy
Этот способ используется к примеру если вы свои приложения публикуете через свой собственный источник в WebPI.»
Вы путаете. WebDeploy входит в WebPI, т.е. можно поставить WebDeploy из WebPI, но не наоборот. Процесс выкатки приложений с помощью WebDeploy c WebPI не связан.
«В наших приложениях используем просто Copy Local для сборки.»
Web или Win? Какой целевой фреймворк? Как настроен сервер?
«Проблем не наблюдается. Так же явно указано что WIF Runtime можно поставлять с приложением не требуя явной установки. social.technet.microsoft.com/wiki/contents/articles/1898.aspx#Q11»
Эээ? Вы об этом?
«Q: My application uses WIF and requires that it be installed as a prerequisite. Can I distribute the runtime files with my application?
A: Absolutely. There is now an additional EULA for the WIF SDK that allows developers to redistribute the WIF runtime with their application when they develop an application using WIF.»
Тут написано, что можно распространять, но не написано, что работает bin deploy.
«Может я вас не полностью понимаю, но вопрос установки WIF и процесс WebDeploy не связаны между собой каким-то явным способом.»
Зато связаны процесс развертывания web-приложения, использующего wif.
«Опишите ваш сценарий развертывания, и можно будет это обсудить»
У нас есть web-приложение, использующее WIF. Когда мы хотим развернуть его на новый, из коробочки Windows Server, сколько всего нам надо туда поставить?
На данный момент мы не нашли способа это сделать (развернуть его на чистый сервер), не ставя туда WIF Runtime через соответствующий msu.
Еще как вариант можно посмотреть сюда:
social.technet.microsoft.com/wiki/contents/articles/4499.deploying-claims-aware-application-to-windows-azure.aspx в части Solution Approach. Но это касательно Azure. Там явно указывается как можно деплоить рантайм.
На чистый сервер уже около полугода не ставлю явным вызовом веб деплоя. Собираю webdeploy пакеты и выкладываю в наш собственный WebPI источник и прописываю все зависимости. Попробую на чистой виртуалке как будет время, может чем и подскажу.
social.technet.microsoft.com/wiki/contents/articles/4499.deploying-claims-aware-application-to-windows-azure.aspx в части Solution Approach. Но это касательно Azure. Там явно указывается как можно деплоить рантайм.
На чистый сервер уже около полугода не ставлю явным вызовом веб деплоя. Собираю webdeploy пакеты и выкладываю в наш собственный WebPI источник и прописываю все зависимости. Попробую на чистой виртуалке как будет время, может чем и подскажу.
Меня смущает, что они пишут про bin deploy Microsoft.IdentityModel, хотя я хорошо помню, что у нас это не взлетело.
«На чистый сервер уже около полугода не ставлю явным вызовом веб деплоя. Собираю webdeploy пакеты и выкладываю в наш собственный WebPI источник и прописываю все зависимости. „
К сожалению, для нас это не вариант.
«На чистый сервер уже около полугода не ставлю явным вызовом веб деплоя. Собираю webdeploy пакеты и выкладываю в наш собственный WebPI источник и прописываю все зависимости. „
К сожалению, для нас это не вариант.
Отвечу отдельным комментом. Заранее извиняюсь.
social.msdn.microsoft.com/Forums/en-US/Geneva/thread/8b715681-8528-4a2d-969c-4dc0e59e0853/
Как раз по теме развертывания рантайма.
social.msdn.microsoft.com/Forums/en-US/Geneva/thread/8b715681-8528-4a2d-969c-4dc0e59e0853/
Как раз по теме развертывания рантайма.
Спасибо за статью!
Как раз сейчас настраиваем и пытаемся развернуть связку AD FS + Azure Cloud + WiF
Как раз сейчас настраиваем и пытаемся развернуть связку AD FS + Azure Cloud + WiF
А какие проблемы возникли во время развертывания?
Во-первых, отсутствие физического доступа к существующему AD-серверу. То есть приходится все делать в лучшем случае через teamviewer, а то и вообще говорить людям, что сделать надо. Такие у них правила работы, к сожалению…
А во-вторых, тяжело отлаживать и разрабатывать такие приложения на компьютере, не подключенном к контроллеру домена… В коде добавляются #if..#endif, и у нас получаются различные конфигурации — debug и release,
А во-вторых, тяжело отлаживать и разрабатывать такие приложения на компьютере, не подключенном к контроллеру домена… В коде добавляются #if..#endif, и у нас получаются различные конфигурации — debug и release,
А я вот что-то не понял, чем это наличие паспорта и проверка его наличия перед выполнением какого-либо защищённого действия отличается от отношения к роли и проверки принадлежности к роли перед выполнением того же действия?..
Решили заглянуть?=)
RBAC становится слишком ограниченной например при федерации. Допустим у вас есть общегражданский паспорт и загранпаспорт. Оба этих документа удостоверяют вашу личность и несут определенный набор утверждений о вас. Только вот по общегражданскому паспорту не выехать на пляжи Испании. Становится важен еще и источник, выдавший удостоверение.
Например у вас может быть 3 утверждения, что пользователь входит в группу администраторов. Каждый выдан своей системой аутентификации и федерации, что достаточно часто встречается как только появляются такие штуки как ADFS, Azure ACS, Oracle IdM, OpenAM. Но вы доверяете только тому утверждению, которое вы считаете достаточным. Если все 3 источника этого утверждения не являются для вас достаточными, то пользователь не получит положительного решения по авторизации.
Можно построить RBAC поверх. Но опять же если у вас требуется авторизация не на уроне роль есть/нет, а права на доступ к конкретным действиям над ресурсами — количество ролей начинает зашкаливать. А если при этом еще где-то поменяется логика, то это потенциально небезопасный код. В случае с набором утверждений, вы можете проводить авторизацию всегда в одном месте. Вы не требуете роль, а просите разрешения. Ваш код не знает какие разрешения нужны для выполнения того или иного действия.
Например:
Стандартный способ для ролей в Asp.Net MVC:
В случае же Claim-based подхода:
Если вас интересует эта тему, можно в личке обсудить. Хотя тут можно статью написать только по этому юзкейсу.
RBAC становится слишком ограниченной например при федерации. Допустим у вас есть общегражданский паспорт и загранпаспорт. Оба этих документа удостоверяют вашу личность и несут определенный набор утверждений о вас. Только вот по общегражданскому паспорту не выехать на пляжи Испании. Становится важен еще и источник, выдавший удостоверение.
Например у вас может быть 3 утверждения, что пользователь входит в группу администраторов. Каждый выдан своей системой аутентификации и федерации, что достаточно часто встречается как только появляются такие штуки как ADFS, Azure ACS, Oracle IdM, OpenAM. Но вы доверяете только тому утверждению, которое вы считаете достаточным. Если все 3 источника этого утверждения не являются для вас достаточными, то пользователь не получит положительного решения по авторизации.
Можно построить RBAC поверх. Но опять же если у вас требуется авторизация не на уроне роль есть/нет, а права на доступ к конкретным действиям над ресурсами — количество ролей начинает зашкаливать. А если при этом еще где-то поменяется логика, то это потенциально небезопасный код. В случае с набором утверждений, вы можете проводить авторизацию всегда в одном месте. Вы не требуете роль, а просите разрешения. Ваш код не знает какие разрешения нужны для выполнения того или иного действия.
Например:
Стандартный способ для ролей в Asp.Net MVC:
[Authorize(Roles="Administrator")]В случае же Claim-based подхода:
Check.Access(Actions.Read, Resources.SomeAdminData);Если вас интересует эта тему, можно в личке обсудить. Хотя тут можно статью написать только по этому юзкейсу.
конечно :)
По большому счёту, любое разрешение и любая привилегия- это тоже способ делить (группировать) пользователей на тех, кто её имеет, и остальных. И роли — это те же привилегии, но чуть более высокого уровня. И паспорта эти — тоже. И организации, их выдающие.
На сколько уровней групп побить взаимосвязь «конкретное действие»-«пользователь» с одной стороны совершенно не важно, а с другой — вопрос открытый, потому что на практике хотелось бы не утонуть в деталях. И разные уровни группировок могут отражать разные принципы деления пользователей и в соответствии с этими принципами называться разрешения, привилегии, роли, группы и т. п.
А в результате — всё равно, приложению надо как-то ассоциировать конкретные действия с конкретным пользователем. И тут есть два варианта того, как это будет заточено на самом низу: предельный и промежуточный. То есть, будет ли иерархия группировок прав на действия доведена до уровня отдельных действий, или остановится где-то на пол пути. Иначе говоря, каждое действие будет проверять, можно ли пользователю делать именно это действие, или каждое действие будет проверять, относится ли пользователь к не делимой далее группе, имеющей разом права как на это действие, так и ещё на кучу других. То есть, будет ли каждое отдельное действие представлено в системе прав отдельно, или взаимосвязь отдельных действий с минимальной их группой (то есть, состав этой минимальной группы) будут зашиты в само приложение.
Когда что-то выносится из настроек и зашивается в код, несомненно, снижается гибкость, но облегчается настройка. Но с другой стороны, формирования зашитого перечня (первичная настройка) всё равно делается, так почему бы эту первичную настройку всё равно не иметь вне кода, в настройках? В виде заготовки минимальных групп. Тогда настройщику можно будет сразу иметь дело ровно с группами того же уровня, какие получились бы при зашивании минимальных групп в код — и проблемы с усложнением настройки не возникает.
С другой стороны, это вынуждает публиковать подробный перечень отдельных действий в систему управления правами. Это само по себе может быть нехорошо, как нарушение инкапсуляции. К тому же, это существенно повышает количество информации, которую должна обрабатывать эта подсистема, что может сказаться на производительности. Исходя из этого, приходится искать компромиссы, всё же зашивая ту или иную часть минимальных групп в код приложения.
Далее. Роли (действия, привилегии) могут быть как уникальными (самодостаточными), типа «Administrator», и параметризуемые (как read <что-то>). Возможность управлять параметризуемыми ролями — отдельная важная фича системы управления ролями. Позволяет схлопывать однотипные роли на уровне их общего списка, разворачивая их до уникальных лишь при назначении.
Далее. Есть авторизация — процесс проверки наличия у вызывающего нужной привилегии перед выполнением действия. Есть аутентификация — проверка того, действительно ли вызывает тот, кем представился (кем себя идентифицировал). Есть сервис по хранению, настройке и использованию дерева привилегий и их групп, связей с ним пользователей, с функциональностью по проверке, есть ли у конкретного пользователя конкретная привилегия.
Я всё правильно излагаю, на Ваш взгляд?
По большому счёту, любое разрешение и любая привилегия- это тоже способ делить (группировать) пользователей на тех, кто её имеет, и остальных. И роли — это те же привилегии, но чуть более высокого уровня. И паспорта эти — тоже. И организации, их выдающие.
На сколько уровней групп побить взаимосвязь «конкретное действие»-«пользователь» с одной стороны совершенно не важно, а с другой — вопрос открытый, потому что на практике хотелось бы не утонуть в деталях. И разные уровни группировок могут отражать разные принципы деления пользователей и в соответствии с этими принципами называться разрешения, привилегии, роли, группы и т. п.
А в результате — всё равно, приложению надо как-то ассоциировать конкретные действия с конкретным пользователем. И тут есть два варианта того, как это будет заточено на самом низу: предельный и промежуточный. То есть, будет ли иерархия группировок прав на действия доведена до уровня отдельных действий, или остановится где-то на пол пути. Иначе говоря, каждое действие будет проверять, можно ли пользователю делать именно это действие, или каждое действие будет проверять, относится ли пользователь к не делимой далее группе, имеющей разом права как на это действие, так и ещё на кучу других. То есть, будет ли каждое отдельное действие представлено в системе прав отдельно, или взаимосвязь отдельных действий с минимальной их группой (то есть, состав этой минимальной группы) будут зашиты в само приложение.
Когда что-то выносится из настроек и зашивается в код, несомненно, снижается гибкость, но облегчается настройка. Но с другой стороны, формирования зашитого перечня (первичная настройка) всё равно делается, так почему бы эту первичную настройку всё равно не иметь вне кода, в настройках? В виде заготовки минимальных групп. Тогда настройщику можно будет сразу иметь дело ровно с группами того же уровня, какие получились бы при зашивании минимальных групп в код — и проблемы с усложнением настройки не возникает.
С другой стороны, это вынуждает публиковать подробный перечень отдельных действий в систему управления правами. Это само по себе может быть нехорошо, как нарушение инкапсуляции. К тому же, это существенно повышает количество информации, которую должна обрабатывать эта подсистема, что может сказаться на производительности. Исходя из этого, приходится искать компромиссы, всё же зашивая ту или иную часть минимальных групп в код приложения.
Далее. Роли (действия, привилегии) могут быть как уникальными (самодостаточными), типа «Administrator», и параметризуемые (как read <что-то>). Возможность управлять параметризуемыми ролями — отдельная важная фича системы управления ролями. Позволяет схлопывать однотипные роли на уровне их общего списка, разворачивая их до уникальных лишь при назначении.
Далее. Есть авторизация — процесс проверки наличия у вызывающего нужной привилегии перед выполнением действия. Есть аутентификация — проверка того, действительно ли вызывает тот, кем представился (кем себя идентифицировал). Есть сервис по хранению, настройке и использованию дерева привилегий и их групп, связей с ним пользователей, с функциональностью по проверке, есть ли у конкретного пользователя конкретная привилегия.
Я всё правильно излагаю, на Ваш взгляд?
Примерно так. Авторизация то же может быть вынесена на стороннюю систему. Есть даже такая штука как XACL.
Основная разница с обычным RBAC — наличие того, кто подтвердил, что этот пользователь входит в данную роль.
Допустим сценарий федерации:
1. Компания поставщик.
2. Компания клиент.
1 решает предоставить пользователям 2 доступ к некоторой части своей CRM для бронирования остатков на складе.
У 1 и 2 есть пользователи входящие в группы Administrator.
Используя Claim-based подход можно вычислить при проверке прав доступа, что утверждение на наличие роли было выдано системой 2 и не дает право на доступ к ресурсам и действиям над системой 1.
Ну и не надо забывать, что ваша система может полностью полагаться на артефакты в удостоверении:
1. Имя
2. Возраст
3. Роли
4. Группы
5. Любые другие утверждения, которые может включить ваш IdentityProvider.
Еще один важный аспект — у вас может не быть доступа к хранилищу пользователей вообще. То есть вы не сможете сделать проверку наличия роли в принципе при обычном подходе.
Ну и с ролями и с группами не так все просто:
Что делать если доступ к ресурсу разрешен только женщинам достигшим 18 лет? Делать роли?
Основная разница с обычным RBAC — наличие того, кто подтвердил, что этот пользователь входит в данную роль.
Допустим сценарий федерации:
1. Компания поставщик.
2. Компания клиент.
1 решает предоставить пользователям 2 доступ к некоторой части своей CRM для бронирования остатков на складе.
У 1 и 2 есть пользователи входящие в группы Administrator.
Используя Claim-based подход можно вычислить при проверке прав доступа, что утверждение на наличие роли было выдано системой 2 и не дает право на доступ к ресурсам и действиям над системой 1.
Ну и не надо забывать, что ваша система может полностью полагаться на артефакты в удостоверении:
1. Имя
2. Возраст
3. Роли
4. Группы
5. Любые другие утверждения, которые может включить ваш IdentityProvider.
Еще один важный аспект — у вас может не быть доступа к хранилищу пользователей вообще. То есть вы не сможете сделать проверку наличия роли в принципе при обычном подходе.
Ну и с ролями и с группами не так все просто:
Что делать если доступ к ресурсу разрешен только женщинам достигшим 18 лет? Делать роли?
Роль системы 1 и роль системы 2, даже если названы идентично «Администратор» — это всё же очевидно должны быть разные роли.
А про роли, отношение к пользователям которых функционально и автоматически зависит от характеристик пользователя — это Вы хорошо напомнили. Роль «18-тилетние женщины» я б завёл, если б роли и система проверки их назначенности позволяли бы инкапсулировать в себе такую проверку.
А про роли, отношение к пользователям которых функционально и автоматически зависит от характеристик пользователя — это Вы хорошо напомнили. Роль «18-тилетние женщины» я б завёл, если б роли и система проверки их назначенности позволяли бы инкапсулировать в себе такую проверку.
правда, по возможности завязывался бы в коде всё равно не на неё, а на конечные привилегии, на доступ к действию.
Дело в том что роли не способны покрыть сложные сценарии авторизации. Роль «18-тилетние женщины» это согласитесь уже перебор. Вырожденный случай. Я видел системы с 300+ ролей. Это ахтунг. Точнее это АХТУНГ!!!
ну, с учётом того, что привилегии на конкретное действие, на мой взгляд, — это те же роли… Тут вопрос исключительно в удобстве настройки дерева и производительности выборок из него.
Если есть код, который должен выполняться только для таких женщин — должна быть роль, связывающая отдельных пользователей с правом выполнять этот код.
Если есть код, который должен выполняться только для таких женщин — должна быть роль, связывающая отдельных пользователей с правом выполнять этот код.
Роль — набор привилегий. Из такого суждения и появляются системы с 300+ ролями. А теперь вопрос: изменились бизнес требования и возраст женщин еще и не должен превышать 30 лет. Еще роль? А как в коде это будет выглядеть? Как будет производиться миграция ролей? Все это очень хрупкие концепции с точки зрения безопасности приложения. Я давно уже не вижу использования чистого RBAC в сложных системах. Группы, роли, утверждения(asserions, claims) — могут в совокупности решать этот вопрос. Но при этом должна быть централизованная точка(и) авторизации и аутентификации, которые могут принимать решения на основе тех или иных признаков. Допустим стандартная ролевая модель развалится, если вам необходимо включать такие сценарии как делегация привилегий, взаимодействие между разными security доменами. Добавьте еще какой-нибудь адаптивный механизм авторизации, который на основе типа аутентификационных данных может отказать в доступе при федерации или делегировании, и туту. Либо адовые костыли либо вас ждут WiF, Spring Security, Sun Metro.
Дык в том то и дело, если меняются бизнес-требования, а система завязана на роли и атомарные привилегии — я делаю другую роль, даю привилегии ей, а у первой отнимаю. А если система будет завязана сама на параметры пользователей — мне придётся лезть внутрь системы и менять что-то там. И, как правило, не в одном месте.
Если вы не делаете явный деманд а делегируете эту задачу стандартному AuthorizationManager, то при изменении требований вам не потребуется вообще никак менять свою логику. А AuthorizationManager может обратиться к любому провайдеру правил авторизации и принять решение. Ваш код здесь никак не участвует.
не, Вы кажется не поняли — если, как Вы говорите, при изменении логики я лезу менять логику в AuthorizationManager, а не в код, то это ровно то, о чём я и говорю. И значит что у меня код и так уже не знает ни про женщин, ни про возраст — про них знает лишь AuthorizationManager в своих настройках (в настройках «ролей» и их привязки к пользователям)
Про фичи, перечисленные Вами в виде
* делегация привилегий
* взаимодействие между разными security доменами.
* адаптивный механизм авторизации, который на основе типа аутентификационных данных может отказать в доступе при федерации или делегировании
я не очень понял, почему они что-то обязаны развалить в RBAC… Или, может, то что я имею ввиду — это уже не чистый RBAC? Ну, если в концепции RBAC не было предусмотрено параметризуемости ролей параметрами операции и пользователя…
делегация — это временное и контекстно-зависимое назначение ролей, да? security домены — это ваш пример про администратора из двух контор? адаптивный механизм — это когда что-то нельзя при входе одним способом и можно при входе другим?
* делегация привилегий
* взаимодействие между разными security доменами.
* адаптивный механизм авторизации, который на основе типа аутентификационных данных может отказать в доступе при федерации или делегировании
я не очень понял, почему они что-то обязаны развалить в RBAC… Или, может, то что я имею ввиду — это уже не чистый RBAC? Ну, если в концепции RBAC не было предусмотрено параметризуемости ролей параметрами операции и пользователя…
делегация — это временное и контекстно-зависимое назначение ролей, да? security домены — это ваш пример про администратора из двух контор? адаптивный механизм — это когда что-то нельзя при входе одним способом и можно при входе другим?
А в классической модели RBAC это и не предусмотрено. Как раз появляются требования поверх простой проверки вхождения пользователя в роль.
Делегация — не просто назначение ролей, а более сложные механизмы типа ActsAs, OnBehalfOf, когда действие выполняется под учеткой одной Identity на основе другой. А это важно и с точки зрения аудита, и с точки зрения авторизации на конечной точке перед выполнение действия.
Security domains — если у вас нет таких сценариев, то могут запросто быть сценарии типа приложения фронт офиса обращаются в бэк офис. Вот два отдельных домена.
Адаптивный механизм — да. Но не только это. Допустим для токена который выдан на основе клиентского сертификата можно установить больший лайфтайм, чем на токен выданный по логину-паролю и тд и тп.
Делегация — не просто назначение ролей, а более сложные механизмы типа ActsAs, OnBehalfOf, когда действие выполняется под учеткой одной Identity на основе другой. А это важно и с точки зрения аудита, и с точки зрения авторизации на конечной точке перед выполнение действия.
Security domains — если у вас нет таких сценариев, то могут запросто быть сценарии типа приложения фронт офиса обращаются в бэк офис. Вот два отдельных домена.
Адаптивный механизм — да. Но не только это. Допустим для токена который выдан на основе клиентского сертификата можно установить больший лайфтайм, чем на токен выданный по логину-паролю и тд и тп.
Делегация ActAs — это, получается, временное назначение «всех» ролей другого пользователя. Самих ролей не касается, добавляется лишь ещё одно условие при поиске привилегий, которые должен отработать механизм авторизации. Типа, проверить не только свои роли и роли, подходящие параметрически под пользователя, но ещё и роли того парня. А аудиту на сами роли вообще как правило наплевать, единственно — нужно чтобы в записываемое описание сессии всякие такие особенности сессии входили.
про домен опять не понял.
про адаптивность — добавляем параметризуемость привязки ролей ещё и контекстом сессии, а в контекст сессии — инфу о способе входа — получаем ту самую адаптивность. Лайфтайм токена — это вообще мимо ролей и прав, насколько я понимаю. Это к управлению сессиями, а не правами в них.
про домен опять не понял.
про адаптивность — добавляем параметризуемость привязки ролей ещё и контекстом сессии, а в контекст сессии — инфу о способе входа — получаем ту самую адаптивность. Лайфтайм токена — это вообще мимо ролей и прав, насколько я понимаю. Это к управлению сессиями, а не правами в них.
Не просто роли, а весь Identity. Допустим запись на диск разрешена только от от определенной учетной записи. При помощи делегации можно реализовать юзкейс, когда юзер от имени этой учетки пишет данные на диск.
Разные домены — юзеры фронта не смешиваются с юзерами бэкенда. Вообще. Хранятся в разных системах, за них отвечают разные люди тд.
Что такое параметризуемость ролей? Вы придумываете франкенштейна на ходу=) Существуют готовые промышленные решения, протоколы и фреймворки для выполнения всех этих задач. Роли — это наборы привелегий. Системы с большим количеством вырожденных ролей(роль=привелегии) считаю плохо спроектированными.
Роли это частный случай, который можно реализовать поверх WiF. Не наоборот.
Разные домены — юзеры фронта не смешиваются с юзерами бэкенда. Вообще. Хранятся в разных системах, за них отвечают разные люди тд.
Что такое параметризуемость ролей? Вы придумываете франкенштейна на ходу=) Существуют готовые промышленные решения, протоколы и фреймворки для выполнения всех этих задач. Роли — это наборы привелегий. Системы с большим количеством вырожденных ролей(роль=привелегии) считаю плохо спроектированными.
Роли это частный случай, который можно реализовать поверх WiF. Не наоборот.
про подмену identity — понял. Это нужно на случай, если авторизацию вдруг завязали на самого пользователя. Но не понял, чем это ломает моего RBAC-франкенштейна
про домены — понял. Но не понял, чем это ломает моего RBAC-франкенштейна
про самого моего RBAC-франкенштейна — тоже понял, что у MS он другой и типа гибче.
Но вот чем так уж плох случай, когда много-много ролей нижнего уровня — суть привилегии — не понял. Ну только если все роли всех логических уровней в единую кучу свалены и мешают в них разбираться — это да, неудобно, но это же лишь интерфейсная проблема.
про домены — понял. Но не понял, чем это ломает моего RBAC-франкенштейна
про самого моего RBAC-франкенштейна — тоже понял, что у MS он другой и типа гибче.
Но вот чем так уж плох случай, когда много-много ролей нижнего уровня — суть привилегии — не понял. Ну только если все роли всех логических уровней в единую кучу свалены и мешают в них разбираться — это да, неудобно, но это же лишь интерфейсная проблема.
В том то и дело: роль-суть привилегия — это уже некорректный способ использования. Вы пытаетесь натянуть все на вырожденный частный случай. Даже дерево не поможет.
Я говорю про то, что WiF это более фундаментально чем простая система ролей. Роли — лишь частный случай. Можете поверх сделать кучу ролей. Но внутри это будет просто набор утверждений выданных доверенной стороной. Ели в вашем коде достаточно этого — пожалуйста. Но считать простые роли — фундаментальным уровнем — не корректно. Даже пример про CheckAccess. Не ваш код требует, а вы запрашиваете разрешения. Это инверсия зависимости. Ваш код не должен знать о том, какие роли существуют в системе.
WiF позволяет независимо от RBAC или другого способа абстрагировать код от механизмов работы с утверждениями(делегацией и тд.). То что вы ролям дорисуете параметры, не поможет передать информацию о них в другую подсеть стороннему приложению.
Я говорю про то, что WiF это более фундаментально чем простая система ролей. Роли — лишь частный случай. Можете поверх сделать кучу ролей. Но внутри это будет просто набор утверждений выданных доверенной стороной. Ели в вашем коде достаточно этого — пожалуйста. Но считать простые роли — фундаментальным уровнем — не корректно. Даже пример про CheckAccess. Не ваш код требует, а вы запрашиваете разрешения. Это инверсия зависимости. Ваш код не должен знать о том, какие роли существуют в системе.
WiF позволяет независимо от RBAC или другого способа абстрагировать код от механизмов работы с утверждениями(делегацией и тд.). То что вы ролям дорисуете параметры, не поможет передать информацию о них в другую подсеть стороннему приложению.
«Но считать простые роли — фундаментальным уровнем — не корректно.»
— почему?? (То, что в Wif фундаментальным понятием выбрано что-то другое — не значит же, что нельзя иначе.)
«Даже пример про CheckAccess. Не ваш код требует, а вы запрашиваете разрешения. Это инверсия зависимости. Ваш код не должен знать о том, какие роли существуют в системе.»…
хм… «Я запрашиваю разрешение на то, чтобы „сделать X“» и «Я спрашиваю, относится ли вызывающий к группе „им разрешено сделать X“» — это просто два способа сказать одно и то же. От этого меняется терминология, и возможно архитектура, но не суть происходящего. Мой код знает лишь про X и выполняет X, если ровно это было дозволено. И не важно, что это — роль привилегия или ещё что там у вас в WiF
Последний абзац я не понял. Зачем мне их передавать? Я проверяю права на мои действия, и я передаю параметризующий контекст про эти самые мои действия. Кому они нужны где-то на стороне? Главное, что я не должен ничего знать про более высокие группировки прав, и не знаю.
— почему?? (То, что в Wif фундаментальным понятием выбрано что-то другое — не значит же, что нельзя иначе.)
«Даже пример про CheckAccess. Не ваш код требует, а вы запрашиваете разрешения. Это инверсия зависимости. Ваш код не должен знать о том, какие роли существуют в системе.»…
хм… «Я запрашиваю разрешение на то, чтобы „сделать X“» и «Я спрашиваю, относится ли вызывающий к группе „им разрешено сделать X“» — это просто два способа сказать одно и то же. От этого меняется терминология, и возможно архитектура, но не суть происходящего. Мой код знает лишь про X и выполняет X, если ровно это было дозволено. И не важно, что это — роль привилегия или ещё что там у вас в WiF
Последний абзац я не понял. Зачем мне их передавать? Я проверяю права на мои действия, и я передаю параметризующий контекст про эти самые мои действия. Кому они нужны где-то на стороне? Главное, что я не должен ничего знать про более высокие группировки прав, и не знаю.
Это другой уровень абстракции. Роль — это логическая единица. Утверждение — физическая.
Еще раз. Простой пример. Для выполнения действия требуется роль 1. После изменений требований заказчика — требуется либо 1, либо 2. Теперь интерполируем, это нас систему состоящую из более чем 3-х контроллеров(образно) и получаем, извините за выражение, пи***ц. Это не поддерживаемая система в принципе. Никогда например не сталкивались с требованиями централизованного управления доступом? Отзывом привилегий? Аудитом безопасности гетерогенной системы?
Мы сейчас разговариваем с вами о совершенно разных классах приложений. Давайте так, для предметного обсуждения этого вопроса я настоятельно рекомендую ознакомится с Claims based Identity Guide. Это написано в отношении .Net по большей части, но такой же подход можно встретить и в Java(Sun Metro). Иначе мне придется просто пересказать вам часть этой книги, что не совсем эффективно с точки зрения расходуемого времени =)
Еще раз. Простой пример. Для выполнения действия требуется роль 1. После изменений требований заказчика — требуется либо 1, либо 2. Теперь интерполируем, это нас систему состоящую из более чем 3-х контроллеров(образно) и получаем, извините за выражение, пи***ц. Это не поддерживаемая система в принципе. Никогда например не сталкивались с требованиями централизованного управления доступом? Отзывом привилегий? Аудитом безопасности гетерогенной системы?
Мы сейчас разговариваем с вами о совершенно разных классах приложений. Давайте так, для предметного обсуждения этого вопроса я настоятельно рекомендую ознакомится с Claims based Identity Guide. Это написано в отношении .Net по большей части, но такой же подход можно встретить и в Java(Sun Metro). Иначе мне придется просто пересказать вам часть этой книги, что не совсем эффективно с точки зрения расходуемого времени =)
В Вашем примере сразу же подмена понятия. При использовании того, что мы тут назвали моим RBAC-франкенштейном, для выполнения действия Х требуется примитивная роль «Может выполнять действие Х», и не может случится ситуации, когда для выполнения действия Х понадобится ещё какая-то роль.
Может случится, что действия Х в системе больше не будет — будут действия Y и Z вместо него — тогда надо будет в систему ролей добавлять две новые примитивные роли и убирать одну старую, возможно полу-автоматизированно раздав их туда же, куда была роздана Х, но и при других подходах что-то надо будет аналогичным образом менять в системе доступа, если вводится раздельное управление двумя действиями вместо одного… В любом случае, на этот уровень миллионов примитивных ролей-привилегий админы спускаться будут редко, и управлению на более абстрактных уровнях эти миллионы не должны мешать.
Откуда здесь взяться упомянутому Вами пушному зверю?
А guide гляну, спасибо. Думаю, можем пока остановить эту беседу до нового всплеска интереса.
Может случится, что действия Х в системе больше не будет — будут действия Y и Z вместо него — тогда надо будет в систему ролей добавлять две новые примитивные роли и убирать одну старую, возможно полу-автоматизированно раздав их туда же, куда была роздана Х, но и при других подходах что-то надо будет аналогичным образом менять в системе доступа, если вводится раздельное управление двумя действиями вместо одного… В любом случае, на этот уровень миллионов примитивных ролей-привилегий админы спускаться будут редко, и управлению на более абстрактных уровнях эти миллионы не должны мешать.
Откуда здесь взяться упомянутому Вами пушному зверю?
А guide гляну, спасибо. Думаю, можем пока остановить эту беседу до нового всплеска интереса.
Вы не поверите, но такие слова я уже слышал во время аудита кода где-то год назад. Могу на основе своего опыта сказать, что это не так=) И самое страшное, когда ваши клиенты постоянно требуют доработок, хотят еще какую-то роль или группу, новую функциональность т.д. Допустим, если в соответствие со штатным расписанием у одного клиента кассир имеет право делать один набор операций, а у другого клиента — другой набор. С точки зрения проектирования системы — это роль «Кассир», но для разных клиентов — разный набор привилегий у роли. В код вы это не зашьете. Точнее если это сделаете — то это будет мягко говоря некрасивое решение и не гибкое с точки зрения бизнеса. Роль «Кассир» эфимерна и лишь описывает роль сущности в системе. Понимаете к чему я клоню?=)
Очень полезный документ. Сначала надо осмыслить, но как только начинается интеграция систем или ваша система становится распределенной… это чистый win. После годовой эксплуатации до сих пор поражаюсь гибкости подхода с каждым новым клиентом. Плюс за счет стандартных протоколов — многие головные боли просто не существуют. Интеграция с самописной CRM? Запросто. Интеграция с АБС? Запросто. Наши продукты не знают о них ничего. Инкапсуляция на уровне всей системы, а не только кода.
Очень полезный документ. Сначала надо осмыслить, но как только начинается интеграция систем или ваша система становится распределенной… это чистый win. После годовой эксплуатации до сих пор поражаюсь гибкости подхода с каждым новым клиентом. Плюс за счет стандартных протоколов — многие головные боли просто не существуют. Интеграция с самописной CRM? Запросто. Интеграция с АБС? Запросто. Наши продукты не знают о них ничего. Инкапсуляция на уровне всей системы, а не только кода.
Да, я ж не написал итог по Вашему примеру: в моём случае, роль Х была дана роли 1, а после изменения требований она же будет дана ещё и роли 2. И всё…
Не совсем. Если роли 2 не существовало, вы будете ее везде добавлять. Руками. Это чревато ошибками. Опять же говорим о масштабе проекта. Для маленького — это поддерживаемый вариант. Для большого уже нет.
а в «правильной» системе как это решается?
В правильной вы как требовали доступ к чтению какого-то ресурса, так и требуете. Без перекомпиляции. Вашу систему не должно это касаться.
А на сервисе авторизации просто добавилось бы еще одно правило для этого ресурса. Ну или в xml файле как вам больше нравится(файл как пример, там есть вопросы разграничения доступа к нему и тд).
А на сервисе авторизации просто добавилось бы еще одно правило для этого ресурса. Ну или в xml файле как вам больше нравится(файл как пример, там есть вопросы разграничения доступа к нему и тд).
А, то что Вы называете «требование доступа к ресурсу» — это и есть то, что я называю «примитивной ролью-привилегией». Мы говорим одно и то же, только вы почему-то отказываетесь признавать и критикуете мои слова… «правило авторизации» ваше — это моя «параметризованная привязка роли»…
Правило авторизации может быть сложнее чем простая привязка. В нем вы можете затребовать, что бы у пользователя была роль Кассир, группа пользователи фронт офиса, время доступа от 10.00 до 17.00. Это не решается ролями. Опять же Роль, как сущность в системе олицетворяет собой набор пользователей, привилегий и других ролей. Но самое главное — роль определяет поведение. Можно почитать тут чуточку про терминологию. Она очень важна в таких вопросах. Если начнете читать про Identity Providers, STS и тд — очень пригодится(особенно в разрезе разных протоколов) :) Roles Versus Groups. Но это лишь вершина айсберга…
Все группы так или иначе определяют проведение. И ресурсы, к которым можно давать доступ, тоже.
Если привязка параметризована, то есть имеет условие при котором имеет смысл, то она и есть «правило авторизации».
Я верю, что в спорах о тонкостях смыслов терминов термину «роль» приписывается существенно более узкий смысл, чем я использую в нашем разговоре. И уверен, что в разных конкретных реализациях авторизации смысл в термин «роль» вкладывается несколько разный.
Но в том общем смысле, в каком роль неотличима от группы и привилегии, Вы мне не назвали ничего, что бы не укладывалось в систему из одних лишь ролей с параметризуемыми привязками.
Если привязка параметризована, то есть имеет условие при котором имеет смысл, то она и есть «правило авторизации».
Я верю, что в спорах о тонкостях смыслов терминов термину «роль» приписывается существенно более узкий смысл, чем я использую в нашем разговоре. И уверен, что в разных конкретных реализациях авторизации смысл в термин «роль» вкладывается несколько разный.
Но в том общем смысле, в каком роль неотличима от группы и привилегии, Вы мне не назвали ничего, что бы не укладывалось в систему из одних лишь ролей с параметризуемыми привязками.
А зачем мне доступ к хранилищу пользователей? Если я ими не управляю и про них ничего не показываю — мне они не нужны.
Нужно лишь, чтоб система авторизации, удостоверяющая наличие нужного права у вызывающего, знала, кто вызывает.
Нужно лишь, чтоб система авторизации, удостоверяющая наличие нужного права у вызывающего, знала, кто вызывает.
Вот мы и пришли к вопросу, а как передать то? И тут вступают такие товарищи как SAML, WS-Federation, WS-Trust, SAML2(-P), которые позволяют в удостоверении передавать набор утверждений. Claim это и есть утверждение о том, что пользователь входит в группу, имеет определенный пол, вес и возраст и тд =) Но чистый RBAC для сложных систем все равно уже изжил себя. Я сейчас не могу найти ссылку, попозже поищу, там была целая научная работа по механизмам складывания ролей и групп. Простое «схлопывание» тут не прокатит. Есть Allow/Deny precedence и еще куча правил.
Тот же WiF позволяет вам затребовать вхождение пользователя в роль, но при этом проверить его пол и возраст, не прибегая к явным хакам типа 18AndOlderFemalePerson, так как это не роль, а максимум группа, и такая гранулярность просто прибьет систему при развитии.
Тот же WiF позволяет вам затребовать вхождение пользователя в роль, но при этом проверить его пол и возраст, не прибегая к явным хакам типа 18AndOlderFemalePerson, так как это не роль, а максимум группа, и такая гранулярность просто прибьет систему при развитии.
То есть, есть разные самописные и сторонние сервисы, позволяющие каждый по-своему
1) аутсорсить или не аутсорсить аутентификацию и знание о том, кто нынче текущий пользователь
2) аутсорсить или не аутсорсить хранение ролей и пользователей с их информацией
2) завязывать авторизацию в коде на какие-то уровни группировки привилегий, и с какими-то фичами, типа параметризуемости привилегий параметрами выполняемого действия или параметрами обращающегося пользователя.
А статья про то, что те, кто использует что-то из ранее существующего, может теперь заменить это на некий MS WIF, и получить от этого какой-то бонус. Да?
И, типа, описано одно из типовых ранее существующих решений, указан его минус и показано, как этот минус отсутствует в WIF. Да?
1) аутсорсить или не аутсорсить аутентификацию и знание о том, кто нынче текущий пользователь
2) аутсорсить или не аутсорсить хранение ролей и пользователей с их информацией
2) завязывать авторизацию в коде на какие-то уровни группировки привилегий, и с какими-то фичами, типа параметризуемости привилегий параметрами выполняемого действия или параметрами обращающегося пользователя.
А статья про то, что те, кто использует что-то из ранее существующего, может теперь заменить это на некий MS WIF, и получить от этого какой-то бонус. Да?
И, типа, описано одно из типовых ранее существующих решений, указан его минус и показано, как этот минус отсутствует в WIF. Да?
Именно. WiF Это абстракция от конкретного протокола, которую можно зацепить как на самописный STS так и на промышленное решение типа OpenAM. Так же это унификация механизмов внутри фреймворка. Хотите работать с RBAC — работайте, но он уже строится поверх Claims-based модели. Хотите группы — пожалуйста. Хотите просто набор утверждений — пожалуйста. Ваш код не знает. что аутентификация была произведена через клиентский сертификат или еще как-то. Ваш код не знает какие роли, группы, права необходимы.
Ещё разок наткнулся на эту статью. Перечитал.
Если ещё короче — в распределённой системе пользователь при каждом обращении к серверам сам предъявляет подписанную заранее кем-то, кому этот сервер доверяет, ту или иную информацию о том, какие права или нужные характеристики этот пользователь для этого обращения имеет. Клиент знает, кому что нужно предъявить, и собирает на этот счёт подписи сам, обычно заранее и с кешированием, а сервер не ищет информацию о ролях и правах пользователя каждый раз в хранилище прав, а (например, на основании подписи) доверяет тем сведениям, что при обращении дал ему клиент.
Так?
Если ещё короче — в распределённой системе пользователь при каждом обращении к серверам сам предъявляет подписанную заранее кем-то, кому этот сервер доверяет, ту или иную информацию о том, какие права или нужные характеристики этот пользователь для этого обращения имеет. Клиент знает, кому что нужно предъявить, и собирает на этот счёт подписи сам, обычно заранее и с кешированием, а сервер не ищет информацию о ролях и правах пользователя каждый раз в хранилище прав, а (например, на основании подписи) доверяет тем сведениям, что при обращении дал ему клиент.
Так?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Claims-based identity