Создание системы авторизации

Необходима система распределённой авторизации на своём и партнёрских проектах.

Необходимо по пунктам:
1. Распределённая БД пользователей, по типу как Оpеn ID
2. Вся информация об аккаунте хранится на сервере где была осуществлена регистрация, если этот сервер/проект поддерживает это, если нет то вся информация хранится на главном сервере.

Дополнительно:
При использовании Wеb-клиента или специального софт-клиента авторизация должна происходить через него. При разрешении "автологин" должен совершаться автоматический вход на проект(ы).



Остается единственный вопрос, как оставить возможность работы аккаунта если сервер где зарегистрирован пользователь недоступен по каким то причинам?!

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

Для таких случаев поднимают резервные сервера и создают кластер. К примеру MySQL NDBcluster для хранения данных на нескольких машинах.

Да согласен. Но в данном случае это не вариант. Нужна возможность быстрого и простого развертывания на любом проекте. Реализуемого либо с помощью АPI.
Кстати а если сервер авторизации ОpеnID недоступен, возможна ли авторизация на проектах возможна под индентификаром пользователей на зарегистрированныхэтом сервере.

А как насчёт кеширования по типу виндовсовского? когда вход клиента выполняется n раз даже при отсутствии контроллера домена. там это дело опирается на хорошо защищённое локальное хранилище и левого клиента подсунуть затруднительно. можно организовать нечто подобное и у ваших клиентов.

Неочень понял принцип работы. Поподробней если можно.

Допустим, есть сервер входа(св), клиент и сервер данных(сд).
авторизация проходит примерно так(считаем, что защищённое подключение уже есть):
1. клиент отправляет свои учётные данные на сервер входа
2. св сверяет их со своей бд
3. если клиент свой, то св выдаёт выдаёт ему маркер доступа(подписанный св пакет с указанием прав пользователя и времени жизни).
4. клиент идёт к серверу данных, который проверяет маркер и далее обслуживает клиента.
смысл в том, что использование этого маркера контролируется самим клиентом. то есть сд для проверки маркера не всегда запрашивает св, а удовлетворяется тем, что у клиента есть подписанное разрешение на работу с ним(до тех пор пока не будет достигнут предел кол-ва входов клиента без проверки).
когда время жизни маркера проходит(таймер, разрыв сессии, кол-во использований) клиент получает новый. если нет доступных св, то клиент продолжает работать, пока не достигнет лимита на входы без контроля св.

Архитектура проектов такова:
1. главный сервер (СВ)
2. по специальному АPI подключается Сервер Клиентов к гл.серверу, который может выполнять как роль посредника между пользователями и СА (Вся информация тогда хранится на главном сервере) или роль Сервера Авторизиции тогда он выдаёт индентификатор (содержащий полную информацию о пользователе).
3. Пользователь
...

Получение индентификатора:
Т.е пользователь заходит на страницу авторизации любого ресурса при этом подключение между пользователем и сервером шифруется.

Далее пользователь вводит логин/пароль или любую др.связку (сертификат наприм.) После пользователь получает индентификатор который содержит информацию о пользователе и аккаунте (используемые сервисы, и др.данные), т.е маркер.
...
Индентификатор на стороне пользователя есть +
А возможно ли обеспечить каким либо способом соответствие именно того пользователя который после авторизации получил индентификатор с тем кто использует этот же компьютер или устройство?
...
А что будет если пользователь клиента войдёт с чужого Пк или устройства?
...

А что предоставляет сбой маркер? Как он привязывается к пользователю?

Маркер-это по сути временный сертификат, который привязывается к конкретной системе\пользователю. от того каким образом будет сделана эта привязка и от того где и всё как будет хранится и зависит сможет ли пользователь войти с чужого пк. привязаться то можно к ос\железу(зайти с чужой системы не получится), к пользователю системы(другой пользователь не сможет воспользоваться чужими данными), к клиенту(имея с собой настроенного клиента, например, на флешке, пользователь сможет работать откуда угодно. разумеется, в клиенте придётся предусмотреть защиту от похищения).
собственно, идея взята у kerberos. вот тут написано что и как: ссылка

Идея имеет все шансы жить. Но Kеrbеroz это сетевой протокол. :-(

Может кто нибудь помочь с решением этого вопроса?