Мы сделали две вещи с устаревшими аккаунтами. (устаревшие веб-приложения)
Сначала мы сопоставили устаревшие учетные записи с их учетными записями входа в систему (работающими в Windows Active Directory).
Затем поверх поверх устаревших приложений (через веб-интерфейс) был применен фасадный экран входа в систему, который запросил бы вход в AD, который затем изменил бы сопоставление с учетной записью входа устаревших приложений и назначил соответствующие права пользователю, используя устаревшую модель безопасности систем. Пользователь получил токен для сеанса, который оставлял двери для них открытыми.
Это дало нам преимущество в том, что не нужно было модифицировать устаревшие приложения (например, то, что произошло бы, если бы приложение х имело только цифры для идентификатора, а пользователь использует вход в систему Windows (буквенно-цифровой), а также достигло единого входа в систему psuedo из точка зрения клиента.
Другой вариант, который имел смысл, был на новом экране входа в систему, он проверял бы несколько репозиториев безопасности, поэтому даже если пользователь не решил использовать свой вход в Windows, он мог бы войти в систему с прежним именем учетной записи. Очевидно, что это имеет некоторые побочные эффекты, но также может помочь облегчить переходную боль, и конечные пользователи иногда чувствуют перемещение между системами.
Существуют также такие программы, как Citrix XenApp Single Signon , которые используют совершенно другой подход к проблеме.