Single-Sign-On и организация пользователей по Эккаунтам в Коммунити

Single-Sign-On и организация пользователей по Эккаунтам в Коммунити

Всем привет,

как вы знаете, коммунити юзера можно создать только с Контакта, который имеет Эккаунт.

Эккаунт - это фактически какая-то внешняя организация, и через Эккаунт идет шеринг ее записей для сотрудников организации, представленных в виде ее Контактов.

Таким образом привязка Контакта под определенный Эккаунт имеет ключевое значение, так как дает доступ к записям.

Ну и вопрос, каким же образом создаются подобные контакты и из них создаются коммунити юзеры?

Пока все делается вручную внутренним юзером, то все под контролем, он знает что делает.

Но если речь идет о саморегистрации коммунти юзеров? Как привязать пользователя к Эккаунту и при этом не наделать проблем? Да, пользователь может указать, к какой Организации он принадлежит, но мы не можем ему так просто верить, и взять и привязать (и дать доступ к записям). Как это все решается? Как весь этот процесс организовать БЕЗ участия внутренних пользователей (им понятно не хочется с этим возится).

У меня есть вариант решения для создания коммунити юзера через Single-Sign-On (что по логике очень похоже на саморегистрацию). Но это еще теоретический вариант, поэтому выношу на обсуждение.

Во момент захода в систему через Single-Sign-On нового коммунити юзера, мы не знаем к какой организации он принадлежит, и даже если он нам это скажет - мы ни за что не поверим, поэтому:

SSO JIT handler налету создает:
(1) Новый Эккаунт (рек тайп Individual, к примеру);
(2) К нему создается новый Контакт;
(3) Коммунити Юзер (Коммунити Плас лицензия);

После этого пользователь оказывается в коммунити, для него почти все доступно, но при этом не имеет особого смысла: никакие записи с ним не пошерены, новые создать невозможно, так как для их создания пользователь должен иметь Эккаунт с рек тайпом "Organization" (к примеру).

Пользователь видит сообщение на домашней странице:
"Для начала работы, пожалуйста завершите оформление своего эккаунта"

Далее два варианта действий:

(1) Создать новую Организацию и стать ее Лид юзером.
Пользователь вводит primary key организации (номер налогоплатильщика, к примеру)и другую информацию о ней, и если такая организацию еще не создана, то его Эккаунт апдатируется новой информацией, рекорд тайп меняется на "Organization", Контакт пользователя помечается как Лид, и все: новая организация с Лид юзером создана, можно работать.

Если такая организацию уже оформлена в системе, то пользователю предлагается следующее (это и есть второй вариант действий).

(2) Присоединится к существующей организации как ее член или независимый брокер (опять используется primary key организации для ее безошибочного поиска. Если такая организацию внезапно еще не создана, то предлагается вариант 1).

В таком случае пользователь создает запрос (запись кастомного объекта), в котором просит присоединиться к организации. Система шлет уведомление Лид пользователю указанной организации. Лид пользователь имеет доступ ко всем запросам на присоединение к его организации, и если он с ним согласен, то:
(2-1) для нового члена организации происходит re-parenting его Контакта, Контакт привязывается к Эккаунту организации, старый удаляется, все: welcome aboard.
(2-2) для временного брокера происходит шеринг/аншеринг Эккаунта организации, брокер (оставаясь на своем Individual Эккаунт), получает доступ к записям организации и, возможно, не одной.

(3) Если пользователь пытается создать новую организацию, а система показывается, что она уже создана, но пользователь не согласен с таким поворотом, он подает Кейс внутренним пользователям, разобраться в чем дело. Это единственный сценарий, когда внутренние пользователи вступают в игру.

А кто выступает в роли SAML identity provider? Может там уже есть информация к кому принадлежит пользователь?

akr0bat
Может там уже есть информация к кому принадлежит пользователь?

может быть, но не проверенная, источник ее только сам пользователь. мы ее не можем использовать

Скорее всего было бы слишком легко, но есть ли вариант идентифицировать юзера по данным который он вводит? Например домейн имейла? Для того чтобы понять относится ли он к организации.

AntonB
Скорее всего было бы слишком легко, но есть ли вариант идентифицировать юзера по данным который он вводит? Например домейн имейла? Для того чтобы понять относится ли он к организации.

в теории возможно, но мы добавляем его к Эккаунта для того чтобы расшерить с ним записи. Это все чужие записи, и кто будет отвечать, если мы не того включили в Эккаунт? пусть сами разбираются. Даже если бы на входе по SSO было бы поле с primary key организацци, то это все равно была бы инфа от самого входящего юзера, не проверенная.

то это все равно была бы инфа от самого входящего юзера, не проверенная.

у вас должен быть SAML identity provider откуда приходят юзеры по SSO, то есть какая-то система где пользователь авторизован (например Active Directory или другой Federation Server) и информация о нем достоверна.

akr0bat
информация о нем достоверна

не забывайте, что речь идет о коммунити юзерах

Identity Provider для них не дает проверенной информации, там используется саморегистрация для внешних пользователей.

Зачем нужен такой Identity Provider для коммунити? Хороший вопрос, просто политика централизованного Identity Provider для всех типов пользователей, проще контролировать и поддерживать пользователей, в теории пользователь может иметь SSO ко многим системам. Но для коммунити юзеров польза не очень очевидна

Interesting information? Help us, post link to social media..