Да, достойная компания.
У Ping Identity много решений, хороших и разных, но достаточно сложных для малого и среднего бизнеса, на который ориентируемся мы.
Из их решений для малого и среднего бизнеса скорее подойдет PingOne, но что если вам нужно будет хоть немного расширить функционал? Надо покупать дополнительный продукт.
И этот опять же компания с решением для американского рынка, они никогда не будут подстраиваться под нюансы государственного регуляторования IT и бизнеса в нашей стране.
Кстати, на Западе относительно давно пришли к потребности в IAMaaS. Теперь и мы стали продвигать эти идеи в массы.
В отличии от «пинга» мы предполагаем выпустить модульный продукт, как конструктор, где в основной версии есть все «кубики».
Потребителю остается выбрать требуемые, не прибегая к сложным настройкам и покупке нескольких продуктов.
Как я писал выше — есть google.com, а есть и yandex.ru
спасибо за ваши комментарии, взял на заметку.
Про стек применяемых технологий напишу позже отдельную статью и скорее всего не одну.
На сервер-сайде есть всё — Perl, Java, C# и даже PHP :)
Каждому инструментарию отведена своя собственная узкая ниша.
OpenID — всего лишь один из многих протоколов аутентификации. С его помощью можно решить лишь одну из проблем в корпоративном использовании SAAS.
К сожалению, OpenID и OAuth1 на сегодняшний день рядом специалистов по информационной безопасности признаны cсамыми уязвимыми из доступных публичных протоколв…
Потому на сегодня интерес представляют транспорты OAuth2 (хотя и про него есть информация о подверженности CSRF-уязвимости) и SAML2 (хотя с этой технологией есть различного рода иные проблемы, как впрочем и определенные уязвимости, зависящие от средств реализации)
Для этого надо, чтобы любой сервис (хоть публичный, хоть приватный) был способен токены обслуживать.
Мы потенциально готовы взять на себя эту задачу и стать «обёрткой» для таких сервисов
Глубоко ещё не разбирали, но насколько я понимаю стек технологий от MS: WS-Federated является абстракцией более высокого порядка, чем WS-Trust.
Касательно же SAMLP — то он является подмножеством SAML2 (и вроде бы не поддерживается в WIF, хотя есть в AD FS)
Вообщем случае технологии от MS для нас являются одним из вариантов, который мы будем рассматривать. Но не делать на них упор.
С протоколами пока всё очень не просто, ибо OAuth2 имеет баг-репорты о потенциальнй и фактической уязвимости для MIM-атак.
С SAML2 несмотря на наличие титула «стандарт» есть в ряде случаев серьёзные отклоения. Например, в нашем лабораторной реализации, SP от одного известного сервиса принимл наши «сообщени», а SP другого не менее именитого сервиса — нет.
Монополизм в любом своём проявлении — абсолютное зло. Кроме google существует и Яндекс. Кроме hotmail есть mail.ru/
И это хорошо для всех нас.
Onelogin орентирован на американский бизнес.
Поэтому в нём нет и скорее всего не будет сервисов наших.
Американцы не будут связыватся с положениями наших регуляторов, например об обработке ПДн, их трансграничной передаче.
Мы же планируем получить сертификат ФСТЭК.
Так же мы планируем обеспечить глубокую интеграцию с сервисами, не затрагивая сами-по-себе сервисы:
— получение данных из приложений,
— оповещения о событиях,
— гибкие правила управления пользователями и доступами,
— возможность запрета/разрешения определенных функций в приложениях
А кто это будет делать? Вендоры? Потребители?
С ACS проблема интеграции ложится на плечи потребителя, или, в лучшем случае — интегратора, которого потребитель наймет.
В добавок — эта технология решает только часть обозначенных проблем.
Тем, что это решение применимо только для сервисов на платфоре Azure.
Мы же планируем работать с любыми SAAS-продуктами, не зависимо от технологии реализации.
Для «зоопарка» корпоративного ПО в модели «оn-premise» существует уже большое количество решений. А вот готовых и проверенных решений в области SAAS пока что нет.
Да, вы абсолютно правы. Но наличие этих каналов доставки OTP лучше, чем их отсутсвие.
В добавок, e-mail можно рассматривать, как очень слабую защиту, но бесплатную.
SMS по сравнению с e-mail конечно же надёжнее, но и платить за это кому-то надо.
Использование персональных токенов — ещё затратнее.
Я считаю, что наша задача дать возможность бизнесу использовать разные варианты.
Ни одна технология, к сожалению, не является универсальной для решения абстрактно всех задач. Потому и «облачные» технологии имеют свои области применения, и, разумеется, свои противопоказания.
Задача специалиста знать — какой инструмент в каких ситуациях применять. Ну и иметь доступ к «ящику с инструментами» :)
В целом не плохо.
Только вы зря используете термин «кластер».
В общеустоявшмся понимании, «кластер» — это совокупность нескольких отдельных серверов баз данных (несколько отдельных машин), а не несколько разных баз в одном сервере.
И такая ваша трактовка сильно сбивает с толка.
в не подскажете алгоритм, как «схлопнуть» несколько произвольных коммитов в текущей ветке в один?
Пример:
Допустим у нас есть коммутативное множество коммитов A | B | C| D | E
Каким способом можно из него получить эквивалентное множество вида B | (A+C+D) | E или A | (B+C) | D | E или хотя бы A | B | (C+D+E).
У Ping Identity много решений, хороших и разных, но достаточно сложных для малого и среднего бизнеса, на который ориентируемся мы.
Из их решений для малого и среднего бизнеса скорее подойдет PingOne, но что если вам нужно будет хоть немного расширить функционал? Надо покупать дополнительный продукт.
И этот опять же компания с решением для американского рынка, они никогда не будут подстраиваться под нюансы государственного регуляторования IT и бизнеса в нашей стране.
Кстати, на Западе относительно давно пришли к потребности в IAMaaS. Теперь и мы стали продвигать эти идеи в массы.
В отличии от «пинга» мы предполагаем выпустить модульный продукт, как конструктор, где в основной версии есть все «кубики».
Потребителю остается выбрать требуемые, не прибегая к сложным настройкам и покупке нескольких продуктов.
Как я писал выше — есть google.com, а есть и yandex.ru
PS со ссылкой появился только после обсуждений.
с удовольствием побеседуем
Про стек применяемых технологий напишу позже отдельную статью и скорее всего не одну.
На сервер-сайде есть всё — Perl, Java, C# и даже PHP :)
Каждому инструментарию отведена своя собственная узкая ниша.
К сожалению, OpenID и OAuth1 на сегодняшний день рядом специалистов по информационной безопасности признаны cсамыми уязвимыми из доступных публичных протоколв…
Потому на сегодня интерес представляют транспорты OAuth2 (хотя и про него есть информация о подверженности CSRF-уязвимости) и SAML2 (хотя с этой технологией есть различного рода иные проблемы, как впрочем и определенные уязвимости, зависящие от средств реализации)
Мы потенциально готовы взять на себя эту задачу и стать «обёрткой» для таких сервисов
Касательно же SAMLP — то он является подмножеством SAML2 (и вроде бы не поддерживается в WIF, хотя есть в AD FS)
Вообщем случае технологии от MS для нас являются одним из вариантов, который мы будем рассматривать. Но не делать на них упор.
С протоколами пока всё очень не просто, ибо OAuth2 имеет баг-репорты о потенциальнй и фактической уязвимости для MIM-атак.
С SAML2 несмотря на наличие титула «стандарт» есть в ряде случаев серьёзные отклоения. Например, в нашем лабораторной реализации, SP от одного известного сервиса принимл наши «сообщени», а SP другого не менее именитого сервиса — нет.
И это хорошо для всех нас.
Onelogin орентирован на американский бизнес.
Поэтому в нём нет и скорее всего не будет сервисов наших.
Американцы не будут связыватся с положениями наших регуляторов, например об обработке ПДн, их трансграничной передаче.
Мы же планируем получить сертификат ФСТЭК.
Так же мы планируем обеспечить глубокую интеграцию с сервисами, не затрагивая сами-по-себе сервисы:
— получение данных из приложений,
— оповещения о событиях,
— гибкие правила управления пользователями и доступами,
— возможность запрета/разрешения определенных функций в приложениях
«Больше товаров хороших и разных!» (с)
В ближайших планах OAuth2, SAML2 и WS-Federated
С ACS проблема интеграции ложится на плечи потребителя, или, в лучшем случае — интегратора, которого потребитель наймет.
В добавок — эта технология решает только часть обозначенных проблем.
Мы же планируем работать с любыми SAAS-продуктами, не зависимо от технологии реализации.
В добавок, e-mail можно рассматривать, как очень слабую защиту, но бесплатную.
SMS по сравнению с e-mail конечно же надёжнее, но и платить за это кому-то надо.
Использование персональных токенов — ещё затратнее.
Я считаю, что наша задача дать возможность бизнесу использовать разные варианты.
Задача специалиста знать — какой инструмент в каких ситуациях применять. Ну и иметь доступ к «ящику с инструментами» :)
Только вы зря используете термин «кластер».
В общеустоявшмся понимании, «кластер» — это совокупность нескольких отдельных серверов баз данных (несколько отдельных машин), а не несколько разных баз в одном сервере.
И такая ваша трактовка сильно сбивает с толка.
Пример:
Допустим у нас есть коммутативное множество коммитов A | B | C| D | E
Каким способом можно из него получить эквивалентное множество вида B | (A+C+D) | E или A | (B+C) | D | E или хотя бы A | B | (C+D+E).