Внешняя авторизация пользователя на Xpages

Тема в разделе "Lotus - Xpages", создана пользователем krn, 8 апр 2011.

  1. krn

    krn Гость

    Уважаемые коллеги, встала задача создать сайт на основе XPages, который поддерживал бы собственную авторизацию пользователей, не являющихся пользователями Lotus Domino. Для обеспечения безопасности авторизацию желательно организовать посредством сессии пользователя, а не через куки. Есть ли уже готовые решения по этому вопросу или хотя бы идеи по реализации?

    По умолчанию при использовании XPages генерируется сессия, номер которой можно увидеть в числе URL параметров (sessionID). Можно ли использовать эту сессию в качестве безопасной сессии пользователя и если можно, то как?

    Версия сервера Domino: 8.5.1

    Спасибо.
     
  2. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.079
    Симпатии:
    300
    что значит внешняя, домина поддерживает авторизацию по внешнему ЛДАП (читать про DA)
     
  3. rinsk

    rinsk Lotus team
    Lotus team

    Регистрация:
    12 ноя 2009
    Сообщения:
    797
    Симпатии:
    78
    Безопасность авторизации совсем не этим обеспечивается. Все эти "сессии пользователя" есть те же яйца (кукайки:facepalm:) только в профиль - кроме канальной авторизации ест-сно...

    А по сути вопроса - генерите сессионные куки и не парьтесь:)
    ИМХО тут интересно - как будет себя вести для анонимуса xpage разные ...Scope.
     
  4. krn

    krn Гость

    Добавлено:
    Ну уж тут извините. Авторизация на основе куков, как вам известно, хранит данные на стороне пользователя и их очень даже несложно вскрыть. Сессионная авторизация поддерживается самим веб сервером и что-либо с ней сделать уже проблема.

    Добавлено:
    Я объяснил что значит внешняя - авторизация пользователей, не являющихся пользователями домино, производимая непосредственно приложением, созданным на XPages. Все пользователи работают под одним пользователем Domino с именем Anonymous, но приложение должно их различать и ограничивать доступ неавторизованных пользователей к ресурсам Lotus Domino через http. Т.е. любой желающий должен иметь возможность зайти, зарегисться, и работать под своей учеткой. Причем тут LDAP?
     
  5. rinsk

    rinsk Lotus team
    Lotus team

    Регистрация:
    12 ноя 2009
    Сообщения:
    797
    Симпатии:
    78
    Не буду спорить. Более тщательное изучение вопроса принесет Вам немало сюрпризов:facepalm:

    Просто здорово!:) Еще раз прочитайте, что Вы написали.
    А регится - это что за такая воздушная процедура? Может подумать о том, что при регистрации вполне так можно завести запись в LDAP? Тогда и LDAP вполне так причем оказывается...
    Вообще говоря, отказ от использования встроенных средств аутентификации можно лишь объяснить соблюдением лицензионной политики. Или есть иные соображения?
     
  6. krn

    krn Гость

    Да. Тут есть смысл. Спасибо за идею. Есть ли какие-нибудь примеры использования такого взаимодействия? Точнее даже можно сформулировать: каким образом ограничить доступ неавторизованного юзера к ресурсам Domino?
     
  7. rinsk

    rinsk Lotus team
    Lotus team

    Регистрация:
    12 ноя 2009
    Сообщения:
    797
    Симпатии:
    78
    Коллега уже подсказал : DA - Directory assistance. Подробнее в хелпе админа.
    Как и везде:facepalm: Настроить права доступа. Все есть в хелпе.
     
  8. krn

    krn Гость

    Спасибо. Попробую.
     
  9. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.079
    Симпатии:
    300
    rinsk в мягкой форме всё объснил :)
    от себя добавлю: хэпаги - это доминошная шняга и секурити у неё доминошная, если делать "кастылики" - сиборим доп. дырки...
    если ставить фронтэнд (типа томкат/нжикс/индеец) то можно его секурную модель задейстовать, но городить подобные конструкции, а вход делать под одним юзером домины - это классика для взлома
    т.е. ломаем хотябы одного юзера фронтэнда - капец базе (т.к. для неё любой юзер извне - единственный)

    при варианте с ЛДАП - юзеры получат права на основе модели домины, если нет групп для этих имён (именно именами будут представлены аккаунты), то права будут на уровне -Default-, либо др. ентрисов ACL соответ. внешним именам
    +секурити на уровне ридерс/авторс
     
  10. krn

    krn Гость

    Все куда проще. Проанализировал механизм авторизации на php. Механизм элементарный: если пользователь ввел верные логин и пароль, то в сессии пользователя создается какая либо переменная, например, userID. При открытии каждой странички этот параметр проверяется и принимается соответствующее решение. Кто мешает сделать тоже самое в лотусе? Аналогичным образом создаем в Session Scope какую либо переменную, например, userID, присваиваем ей значение UNIDa документа с пользователем и дальше при открытии каждой XPages анализируем значение этой переменной. Собственно все.
     
  11. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.079
    Симпатии:
    300
    ничего не понятно...
    юзер ввёл какой пароль? доминошный - тогда причём тут внешняя авторизация
    если нет - то юзер будет не авторизован доминой, со всеми вытекающими последствиями...
     
  12. krn

    krn Гость

    Кто говорит о доминошных юзерах и их паролях? Вопрос изначально был направлен на то как сделать авторизацию пользователя не средствами домино. Любой желающий может себя зарегистрировать и твое приложение должно само его авторизовывать, разрешать доступ к авторизованным ресурсам и запрещать к неавторизованным. В этом контексте механизм, описанный мною выше как нельзя кстати. Пользователь регится на сайте, для него в базе создается документ. Потом он авторизуется согласно заполненной форме, в Session Scope добавляется переменная UserID, равная UNIDу документа пользователя или что угодно, и эта переменная живет только в рамках этой сессии. на основании эой переменной при открытии любого ресурса принимается решение либо допускать к ресурсу либо перенаправлять на форму регистрации. По-моему все просто. Но стало это возможным только с появлением XPages Scope Variables.
     
  13. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    это было возможно всегда :)
    обычный cookie.
     
  14. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.079
    Симпатии:
    300
    krn пошли на круг...
    выше уже всё объяснили, есть желание сделать дырявую авторизацию - делайте, много студентов и прочих "творцов" понаделали дырявых двигов, в тырнете...
    присоединяйтесь :)
     
  15. krn

    krn Гость

    lmike, приведите пример вскрытия сессии сервера. Переменные сессии устанавливаются непосредственно кодом, исполняемом на сервере. Так в чем дырявость то?
     
  16. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    to krn:
    Вы, в принципе, все верно пишете. Более того, именно такой механизм успешно реализован в domino session authentication.
    Оно конечно будет работать. НО только при условии, что все сделано верно.

    То, что переменная устанавливается кодом на сервере, никоим образом не гарантирует, что в этом коде нет ошибок.
    Например, ваше предложение использовать unid документа в качестве ключа сессии - очевидная дыра.

    Вообще проблем несколько:
    0. Собственно процедура логина. Если нет защиты канального уровня, подходит банальный съем трафика.( разновидность man in the middle )
    1. Аутентификация: воcстановление имени пользователя по sessionId.
    Взаимно-однозначное соответсвие не подходит, т.к. ничем не лучше, чем каждый раз слать логин-пароль. Т.о. sessionId должен обладать конечным временем жизни, т.е. должен "протухать" со временем - нужно уметь генерить именно "сессионый" ключ.
    Как будете восстанавливать имя пользователя по sessionId?
    Что будете включать в состав ключа, кроме username: время создания? IP пользователя? порт? User-agent?
    Как будете защищаться от подделки ключа? от перехвата?
    Как будет передаваться ключ: в URL? в cookies? в других заголовках http? в теле запроса?
    Как защищаться от попадание ключа в различные кэши: кэш браузера, прокси?
    Как будете хранить пароль пользователя в БД?

    2. Авторизация.
    Самое вкусное. В php обычно в бекенде сидит реляционка, и при обращениях к ней за данными фигурирует username, полученный на этапе аутентификация. Кроме как через соотв. селекты, данные получить невозможно. Т.о. существует единая точка входа к уровню данных.
    В домино такой точки нет. Есть стопицот способов получить данные из домино через веб. Вьюхи, формы, документы, агенты, xpages и пр. При использовании доминошной авторизации всю эту кухню можно защищать штатными средствами. В вашем случае, вы должны будете вручную закрыть ВСЕ возможные входы.
    Вы обязательно что-нибудь забудете закрыть. Ничего личного. Я чуть-чуть давно работаю с домино, в т.ч. с веб, но до сих пор не готов построить защищенное веб-приложение, без использования "штатных" механизмов ограничения доступа.
    Количество нюансов, связанных с аутентификацией/авторизацией таково, что не стоит пытаться делать это самому - это классический пример переизобретения велосипеда. При этом гарантировано, что с первой попытки у вас получится очень хреновый велосипед. Однако, в отличие от других програмерских ошибок, косяки в модулях безопасности воспринимаются заказчиком наиболее болезненно.
    Хочется пройтись по этим граблям - велкам.
    P.S. В качестве разминки: как будете закрывать доступ к документу, содержащем мои логин, пароль( я надеюсь, что не открытом виде ) и скан паспорта в RT поле?
     
  17. krn

    krn Гость

    Turumbay, спасибо за развернутый ответ. Я согласен, что проблем много и при изобретении собственного велосипеда придется заново набить все шишки, которые уже были набиты разработчиками первоначального велосипеда. Более того, как вы правильно заметили, не все шишки можно поймать, даже при желании, ибо тонкости архитектуры Domino либо скрыты, либо малоизвестны. И никто не гарантирует, что при реализации внешней авторизации будут закрыты все дыры.

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

    Но данная задача возникла не на пустом месте, а на желании руководства предоставить внешний интерфейс к существующей ИС через интернет. И при стоимости одной лицензии Notes Enterprise в 4750р предоставить доступ к ИС посредством собственной авторизации Domino весьма и весьма накладно.

    Есть другой путь, и он сейчас тоже рассматривается - реализовать web часть на сторонней технологии, которая обращалась бы к Domino посредством защищенных web сервисов. Механизм не самый простой и не самый быстрый, но весьма безопасный.
     
  18. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.079
    Симпатии:
    300
    и как бум хранить связку юзер-пароль, к домине? :)
    маппинг делать, общий вход (под одним юзером) использовать или всё-таки доминошную авторизацию ;)?

    Добавлено:
    внешний ЛДАП подцепленный доминой - более "тонкая материя", в плане цены ;)
     
  19. lmike

    lmike нет, пердело совершенство
    Команда форума Lotus team

    Регистрация:
    27 авг 2008
    Сообщения:
    6.079
    Симпатии:
    300
    http://www-01.ibm.com/software/lotus/notes.../licensing.html
     
  20. turumbay

    Регистрация:
    13 мар 2009
    Сообщения:
    625
    Симпатии:
    2
    Там все не просто с этими PVU. Грубо говоря, 100pvu = 1 ядро. Найти сервер с числом ядер меньше четырех - надо постараться. ( Закон Мура беспощадно продолжает работать, а прайс IBM и ныне там )
    Итого 400 pvu, т.е. порядка 10 килобаксов за пустой express. При этом за клиентские места нужно платить отдельно. Короче - очень спорный прайс.
     
Загрузка...

Поделиться этой страницей