Смена состояния пользовательской веб сесси

[lionk]

Вобщем вопрос вот какой.
Можно ли как то сменить пользовательскую веб сессию с анонимной на авторизированную на стороне сервера (в ssjs к пирмеру).

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

вроде всё просто, в примере на PHP пользователя авторизировали одной командой.

но как это сделать в лотусе?

 

[rinsk]

Это использование CAS - типа такого:

Ссылка скрыта от гостей

Самому интересно. Все в общем то обычно - главная затыка - сгенерировать LTPA токен для полученного от CAS пользователя...

 

[rinsk]

Пример генерации LTPA токена:

Ссылка скрыта от гостей

https://github.com/markleusink/Auto...F/src/com/developi/openntf/LtpaGenerator.java

ктоб собрал все в кучу)

 

[alexas1]

но как это сделать в лотусе?

А нафига в домине на авторизации токен? И зачем на гуглу смотреть? У него свои тараканы.
Если юзер доминошный то:
юзер конектится на хепагу, для которой разрешен anonimous (настраивается в ACL xpages: All Properties Xpage -> data\acl) с нужной инфой
дальше, или кнопа "войди не понарошку", либо, автоматом, скриптом на beforePageLoad вызвать логин-диалог или логин-страничку и, при успехе, средиректить с этой странички на нужную. Можно редиректить, в зависимости от прав, на разные странички.
Или, в зависимости от ACL разрешить напр. редактирование:

Спойлер

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
................................
  <xp:this.acl>
	<xp:acl>
	   <xp:this.entries>
		  <xp:aclEntry type="ANONYMOUS" right="READER"></xp:aclEntry>
		  <xp:aclEntry type="DEFAULT" right="EDITOR"></xp:aclEntry>
	   </xp:this.entries>
	</xp:acl>
</xp:this.acl>
...................................
</xp:view>

Примеров логин-диалогов в инете море.
=================================
А если не доминошный, то токен, хотя он не решает проблем секурити.
Тут действия - запросить у сервера некую инфу на некий пароль (это уж своя "секуризация"). Сервер отдаёт её с некой "защитой" (токен)
и дальше тот же редирект или разрешения на редактирование.
И не надо тут ничего мудрить, задачи стандартные: запросить у сервака инфу (обратившись к агенту или, хоть, попробовать её найти напр. в вьюшке по ключу)\получить ответ\отреагировать нужным образом.

 

[rinsk]

А нафига в домине на авторизации токен?

Есть задачи - SSO с региональными системами, которые юзают CAS...
Я не говорю об 2-факторке...

 

[alexas1]

Есть задачи - SSO с региональными системами, которые юзают CAS...
Я не говорю об 2-факторке...

В вопросе @lionk этого нет. А домысливать можно всё, что угодно...

 

[lionk]

Примеров логин-диалогов в инете море.

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

LTPA - токен

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

Ссылка скрыта от гостей

а где взять
public final String SSO_DOMINO_SECRETFIELD="LTPA_DominoSecret";
public final String SSO_DOMINO_DURATIONFIELD="LTPA_TokenExpiration";
из этого примера?
https://github.com/markleusink/Auto...F/src/com/developi/openntf/LtpaGenerator.java

почитал апи.
в ssjs есть такой вызов session.getSessionToken() должен дать текущий токен пользователя.
засунул компутед поле - получаю ошибку, ЧЯДНТ?

 

[rinsk]

а где взять
public final String SSO_DOMINO_SECRETFIELD="LTPA_DominoSecret";
public final String SSO_DOMINO_DURATIONFIELD="LTPA_TokenExpiration";
из этого примера?

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

в ssjs есть такой вызов session.getSessionToken() должен дать текущий токен пользователя.

ну а откуда текущий возметься если его еще нет?

 

[lionk]

ну а откуда текущий возметься если его еще нет?

так я ввёл логин пароль, не зажадничал.
а вот домино всёравно null - error лепит как будто такой функции нет.

 

[rinsk]

а вот домино всёравно null - error лепит как будто такой функции нет.

а это делал - " just duplicate your 'Web SSO Configuration' document and clear 'Organization' field on the second one."

 

[lionk]

Web SSO Configuration

стоп, а у меня Single-Server авторизация. неужели она накладывает ограничения.

 

[rinsk]

стоп, а у меня Single-Server авторизация. неужели она накладывает ограничения.

из хелпа - "The name of a server configured for Single Sign-on..."
Вообще говоря .getSessionToken() для первоначальной задачи мало полезно.


Пример из https://github.com/markleusink/Auto...F/src/com/developi/openntf/LtpaGenerator.java можно модиклицировать - в ф-цию
public String generateLtpaToken(String userName) добавить в качестве параметров ,duration и ltpaSecret и можно использовать в LS2J для генерации токена. Надо заметить что это именно генерация LTPA1, что в принципе достаточно для авторизации в домино...

 

[lionk]

Перенастроил на SSO, взял библиотеку и заработало. шок.
Не понятно как но генерит токен, и он рабочий.

Трабла только с кириллицей. Имя залогиненого пользователя выходит таким ?????????/OU/C и соответственно ацл базы не работает.
Залил рекомендуемые либы, не помогло.
Думаю может проблема в лангпаке, если у кого есть к 9.0.1 линукс, поделитесь :angelic:.

 

[rinsk]

Перенастроил на SSO, взял библиотеку и заработало

какую из?
Я public String generateLtpaToken переделал для использования LS2J и оно генерит токен - с редиректом пока не проверял..
Т.е. если из клиента ЛН авторизоватся на сайте - то не нужен getSessionToken... можно будет брать любой ключ с сервера...

 

[lionk]

вот эту.
https://github.com/markleusink/Auto...F/src/com/developi/openntf/LtpaGenerator.java

там же в примере:
response.setHeader("Set-Cookie", "LtpaToken=" + token + "; domain=.developi.info; path=/");
facesContext.getExternalContext().redirect(someUrl);

устанавливаешь куку и просто рефрешиш страничку. домино при рафреше хавает токен и присваивает сессии права пользователя закодированного в токене из куки.

 

[rinsk]

Ну тогда прикрутить CAS нет проблем) и вообще - можно реализовать произвольный алгоритм авторизации в домино - даже по CallBack sms...

 

[rinsk]

Могу сообщить, что jasig CAS к домино прикручен - на очереди SPNEGO\ntlm через CAS+Domino и интеграция c ЕСИАиА (портал госуслуг - SAML).
SPNEGO через CAS привлекателен тем, что не нужны заморочки с членством в домене сервера домино...

 

[lmike]

у меня вопрос, если есть фронт - то зачем токен (доминошный)?
ведь фронт просто может сунуть домине юзера

 

[rinsk]

А как например фронт сунет юзера доминошного?
И зачем фронту его сувать? Если например есть фигова туча сервисов работающих от одного центра авторизации... Что, доминоха рыжый что ли?

 

[lmike]

ну доминошного - это условно - того, кот. домина понимает, здесь больше вопрос - зачем доминошный токен