Вы очень близки с решением для клиентских переменных.
Настройте удаленную базу данных, с которой могут общаться все приложения, либо через DSN, либо через другую единую точку входа (например, WebService).
Выберите общий способ идентификации пользователей во всех ваших приложениях (т. Е. Создайте свой собственный уникальный идентификатор сеанса, возможно, на основе CFID / CFTOKEN, CreateUUID () или чего-то еще, что вы можете гарантировать, является уникальным).
Создайте процесс аутентификации таким образом, чтобы, когда кто-то проходил аутентификацию где-то в вашей ферме приложений ... где угодно ..., этот уникальный идентификатор сеанса сохранялся в удаленной базе данных.
Передача этого уникального идентификатора сеанса из приложенияк прилож.Возможно, добавьте его к своим гиперссылкам или сохраните в клиентских переменных (куки), которые вы упомянули ранее.
Наконец, в логике вашего приложения, которая проверяет, прошел ли кто-то проверку подлинности, перед тем, как заставить их войти снова ....используйте их клиентские переменные (или переданный уникальный идентификатор сеанса), чтобы проверить с удаленным источником данных и подтвердить их, если вы нашли / проверили его.
Это упрощение, но оно является основой для единого входа, идолжен заставить вас думать в правильном направлении.
PS: Держите все свои приложения в одном домене, если это возможно (xx.mysite.com, yy.mysite.com), чтобы ваш клиент мог использовать vars (cookie)быть установленным для конкретного домена, что позволяет им проходить через ферму приложений так, как вам нужно.