Как внедрить единый вход для разных приложений ColdFusion, работающих на одном сервере? - PullRequest
Новая
       16

Как внедрить единый вход для разных приложений ColdFusion, работающих на одном сервере?

7 голосов
/ 16 сентября 2011

У меня несколько приложений CF, работающих на одном сервере под одним и тем же доменным именем.Один из них, назовем его Portal , предназначен для единого входа в другие приложения, которые назовем Atlas и P-Body .Обычно вы устанавливаете некоторые переменные в области действия session для обработки информации для входа в систему: 

function Login()
{
    session.auth = structNew();
    session.auth.isLoggedIn = true;
    session.auth.id = GetCurrentUserId();
}

Но область действия сеанса является общей только для одного приложения, а не для всего сервера.Это означает, что любой пользователь, который входит в систему Portal , останется в системе, но если он попытается перейти к Atlas или P-Body , он должен будет подписатьснова.

В таком случае, как бы я «поделился» областью сеанса, чтобы все приложения на сервере могли получить к ней доступ?Единственный способ, которым я смог придумать, - это использовать клиентские переменные и настроить хранилище данных таким образом, чтобы оно было общим для приложений.Затем код становится следующим: 

function Login()
{
    client.auth = structNew();
    client.auth.isLoggedIn = true;
    client.auth.id = GetCurrentUserId();
}

function Logout()
{
    structDelete(client, "auth");
}

Здесь следует обратить внимание на то, что, поскольку переменная клиента не очищается в конце сеанса, мы должны вручную очистить ее в обработчике OnSessionEnd.

Является ли это лучшим способом обработки единого входа в ColdFusion?Если да, есть ли какие-либо недостатки в использовании клиентской переменной или ловушки, на которые стоит обратить внимание?

Обновление: Я только что протестировал метод клиентской переменной, и он выглядиткак только hitcount, timecreated, lastvisit и urltoken совместно используются приложениями, поэтому я вернулся к квадрату 1.

Ответы [ 4 ]

2 голосов
/ 28 сентября 2011

Вы очень близки с решением для клиентских переменных.

Настройте удаленную базу данных, с которой могут общаться все приложения, либо через DSN, либо через другую единую точку входа (например, WebService).

Выберите общий способ идентификации пользователей во всех ваших приложениях (т. Е. Создайте свой собственный уникальный идентификатор сеанса, возможно, на основе CFID / CFTOKEN, CreateUUID () или чего-то еще, что вы можете гарантировать, является уникальным).

Создайте процесс аутентификации таким образом, чтобы, когда кто-то проходил аутентификацию где-то в вашей ферме приложений ... где угодно ..., этот уникальный идентификатор сеанса сохранялся в удаленной базе данных.

Передача этого уникального идентификатора сеанса из приложенияк прилож.Возможно, добавьте его к своим гиперссылкам или сохраните в клиентских переменных (куки), которые вы упомянули ранее.

Наконец, в логике вашего приложения, которая проверяет, прошел ли кто-то проверку подлинности, перед тем, как заставить их войти снова ....используйте их клиентские переменные (или переданный уникальный идентификатор сеанса), чтобы проверить с удаленным источником данных и подтвердить их, если вы нашли / проверили его.

Это упрощение, но оно является основой для единого входа, идолжен заставить вас думать в правильном направлении.

PS: Держите все свои приложения в одном домене, если это возможно (xx.mysite.com, yy.mysite.com), чтобы ваш клиент мог использовать vars (cookie)быть установленным для конкретного домена, что позволяет им проходить через ферму приложений так, как вам нужно.

2 голосов
/ 16 сентября 2011

Single Sign On (SSO) - нелегкая задача, и есть несколько очень дорогих продуктов, которые помогают это доказать.

К счастью, есть несколько бесплатных проектов OSS.

Есть также много других соображений, касающихся SSO, которые затрудняют его реализацию, например, как вы справляетесь с этим, когда пользователь нажимает кнопку «Выйти» на одном из сайтов? Вы выходите из них всех? Если да, то как?

Если вы хотите сделать единый вход правильно, вам нужно рассмотреть возможность использования единого решения, такого как Shibboleth (FOSS) или Atlassian Crowd (коммерческое решение по разумной цене).

Если у вас нет ресурсов для использования продукта единого входа, подобного описанному выше, то вы в конечном итоге будете взламывать текущие ограничения безопасности, которые делают единый вход таким трудным.

2 голосов
/ 16 сентября 2011

Публикация ответа как новой информации.

Протест

Убедитесь, что все приложения имеют либо а) уникальные имена областей приложения для постоянных переменных, либо б) все переменные области приложения для одной и той же цели имеют одинаковые имена.

Хорошо, с учетом этого, если все ваши приложения находятся в одном домене в подпапках, то измените this.name или атрибут name на cfapplication на то же самое, и все приложения будут совместно использовать те же самые переменные области видимости session и application. Это гарантирует, что если вы используете session.loggedin в одном приложении, одна и та же переменная session.loggedin будет доступна для всех приложений с одинаковым именем в этом домене.

Вам просто нужно тщательно протестировать, чтобы убедиться, что вы не используете Application.LoginService в Portal для своего LoginService.cfc и Application.LoginService в Atlas для другого LoginService.cfc или для совершенно другого назначения. в целом.

0 голосов
/ 16 сентября 2011

Использовать область сервера. Он используется всеми приложениями.

http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec0c35c-7fdb.html

...