kerberosCredentials — это объект типа KerberosAuthorizeCredentials. Сделан был исключительно для расширения механизмов аутентификации в будущем.
Выглядит он так:
public class KerberosAuthorizeCredentials
{
public string Ticket { get; }
public KerberosAuthorizeCredentials(string ticket)
{
Ticket = ticket;
}
}
В общем случае он не нужен, вместо kerberosCredentials.Ticket можно сразу передать строку с kerberos тикетом GitHub
Шаблоны создаются разными способами от ручного редактирования до модификации шаблонов теми же плэйбуками. В зависимости от объема правок, запросы принимаются в течение рабочего дня-двух. Плэйбуки у нас в основном используются всего для создания и модификации тестовых сред.
1. Как было написано в начале статьи, на хабре множество статей про то как писать плейбуки
2. Windows 2019 установлена не на многих машинах. Показанный способ работает и с более старыми версиями
3. 4. Этим занимается отдельный сервис, написанный на python.
5. Чтобы как раз показать разные способы установки приложений
6.7. Спасибо за отзыв, учтем.
3. Очень разнится в зависимости от команды и отделов.
5.1 molecule — molecule.readthedocs.io/en/latest
5.2 реализовано средствами gitlab и ревью merge request.
6. 10-15
1. 4. У нас используется свой сервис, написанный на python.
2. content library, если мне не изменяет память, появилась в VMware vSphere 6, когда данный способ работает для 5.5.
3. в данном примере не имеет значения, как. Это может быть даже виртуальная машина
5. тестирование с помощью molecule, линтеры, code review
Данный пример показывает возможность выполнить playbook фактически на хосте, которого еще нет. Очевидно, что описание машины «Моя машина, клонированная из TemplateName» в production среде неприемлимо. Это упрощенный пример.
Когда мы делали фичу, .Net Core 3 еще был далек от релиза. В целом, мы и сейчас еще не готовы обновляться, поскольку, во-первых, не все используемые нами зависимости поддерживают его, а во-вторых, нам самим при переходе будет необходимо переписать часть инфраструктурного кода.
Прямой и правильный путь для корпоративного портала, если он доступен только из локальной сети — использовать Kerberos. И пользователи будут счастливы, и владельцы.
Если доступен извне и прозрачная доменная аутентификация невозможна, есть альтернативные варианты. Наиболее популярные сейчас — SAML и OpenID Connect
Если основная инфраструктура у вас на продуктах MS, то самый простой путь — ADFS. Большинство опенсорсных IDP, как вы заметили, действительно представляют собой Java- приложения, но, настройка, например Keycloak, не настолько сложна как кажется на первый взгляд.
Тут вопрос в правилах, по которым доступ предоставляется. Если эти правила определены заранее, и на каком-то этапе процесса становится понятно, что пользователь получает доступ, то его (лично, его группу, или роль) можно внести в список доступа документа и тогда при чтении папки нужно будет просто добавить фильтр на уровне запроса в хранилище (БД).
OAuth 2 я вырожденным случаем не называл. Относительно него я говорю, что вы не верно определяете границы системы и подменяете понятия.
Если у меня где-то есть сервис хранения бэкапов, а где-то в другом месте есть авторизационный сервис, который дает третьим системам токены на заливку бэкапов, этот сервис не обязан быть частью сервиса хранения. Вся их связь выражена в контракте на авторизационный токен — и это, заметим, гигантское достоинство, сильно упрощающее и поддержку и развитие обоих сервисов (а так же еще десятка других сервисов, которым тоже нужна авторизация, но не нужна идентификация).
Микросервисы принадлежат одной системе. Если ваш пример переложить на монолит, то можно сказать что репозиторию (я имею ввиду паттерн) не нужно знать какой пользователь внес те изменения, которые он записывает в БД. Естественно не нужно, он предполагает что работает в доверенной среде.
Ну то есть весь OAuth 2 — это вырожденный случай, да? И в прикладных информационных системах он не используется?
Достаточно часто используется, особенно спецификация OpenID Connect, в последнее время.
Bearer token в OAuth 2 выдается authorization server.
Ключевое слово authorization. Выше вы говорите:
Очень важно проводить границы между участниками процесса.
Согласитесь, нельзя авторизовать на доступ к объектам или операциям о которых не знаешь? А если сервер авторизации знает о сущностях системы, то он входит в границы этой системы. Правильно?
Или, скажем, отправка уведомлений (в простонародье — вебхуки) — это вырожденный случай, который в прикладных информационных системах не используется?
Тут, как правило, два варианта, либо без авторизации совсем (на прикладном уровне), либо с идентификацией, хотя бы по api-ключу.
Да, статьи классные. С первой мы еще хотим поспорить, а вторая ссылка в тексте у меня изначально была. Но прошло 4,5 года, а ничего столь же стоящего не появилось. Нужно исправлять!
Соглашусь, данная формулировка не совсем точна, поскольку авторизация без идентификации возможна, к примеру, на сетевом уровне. Однако это скорее вырожденные случаи, не относящиеся к прикладным информационным системам о которых я в первую очередь говорю. Bearer token, как правило, выдан IdP, который все за вас сделал. Формулировку уточнил.
kerberosCredentials — это объект типа KerberosAuthorizeCredentials. Сделан был исключительно для расширения механизмов аутентификации в будущем.
Выглядит он так:
В общем случае он не нужен, вместо kerberosCredentials.Ticket можно сразу передать строку с kerberos тикетом GitHub
Тестового проекта нет.
2. Windows 2019 установлена не на многих машинах. Показанный способ работает и с более старыми версиями
3. 4. Этим занимается отдельный сервис, написанный на python.
5. Чтобы как раз показать разные способы установки приложений
6.7. Спасибо за отзыв, учтем.
5.1 molecule — molecule.readthedocs.io/en/latest
5.2 реализовано средствами gitlab и ревью merge request.
6. 10-15
2. content library, если мне не изменяет память, появилась в VMware vSphere 6, когда данный способ работает для 5.5.
3. в данном примере не имеет значения, как. Это может быть даже виртуальная машина
5. тестирование с помощью molecule, линтеры, code review
Если доступен извне и прозрачная доменная аутентификация невозможна, есть альтернативные варианты. Наиболее популярные сейчас — SAML и OpenID Connect
Микросервисы принадлежат одной системе. Если ваш пример переложить на монолит, то можно сказать что репозиторию (я имею ввиду паттерн) не нужно знать какой пользователь внес те изменения, которые он записывает в БД. Естественно не нужно, он предполагает что работает в доверенной среде.
Согласитесь, нельзя авторизовать на доступ к объектам или операциям о которых не знаешь? А если сервер авторизации знает о сущностях системы, то он входит в границы этой системы. Правильно?
Тут, как правило, два варианта, либо без авторизации совсем (на прикладном уровне), либо с идентификацией, хотя бы по api-ключу.