OpenAM/OpenSSO HttpServletRequest.login (пользователь, pass) терпит неудачу с «Недопустимая транспортная строка». Что это значит?

У меня есть два сервера tomcat, один с OpenAM 12, один с основными веб-приложениями. Известно: страницы HTML аутентифицируются без проблем, программный логин с использованием SDK OpenAM работает из сервлета.OpenAM/OpenSSO HttpServletRequest.login (пользователь, pass) терпит неудачу с «Недопустимая транспортная строка». Что это значит?

Что не может призыв к HttpServletRequest.login (имя пользователя, пароль)

Это запись я имею в TomEE + сервер:

<Realm className="com.sun.identity.agents.tomcat.v6.AmTomcatRealm" debug="99"/>

Здесь ошибка я вижу в журнале отладки AM J2EEAgent:

amRealm:01/29/2014 02:29:47:497 PM EST: Thread[http-bio-443-exec-3,5,main] 
SSOTokenValidator: validate failed with exception 
[AgentException Stack] 
com.sun.identity.agents.arch.AgentException: Invalid transport string 
     at com.sun.identity.agents.util.TransportToken.initializeFromString(TransportToken.java:135) 
     at com.sun.identity.agents.util.TransportToken.<init>(TransportToken.java:115) 
     at com.sun.identity.agents.common.SSOTokenValidator.validate(SSOTokenValidator.java:99) 
     at com.sun.identity.agents.realm.AmRealm.authenticate(AmRealm.java:143) 
     at com.sun.identity.agents.tomcat.v6.AmTomcatRealm.authenticate(AmTomcatRealm.java:106) 
     at org.apache.catalina.realm.CombinedRealm.authenticate(CombinedRealm.java:146) 
     at org.apache.tomee.catalina.TomEERealm.authenticate(TomEERealm.java:43) 
     at org.apache.catalina.authenticator.AuthenticatorBase.doLogin(AuthenticatorBase.java:818) 
     at org.apache.catalina.authenticator.AuthenticatorBase.login(AuthenticatorBase.java:800) 
     at org.apache.catalina.connector.Request.login(Request.java:2621) 
     at org.apache.catalina.connector.RequestFacade.login(RequestFacade.java:1065)

источник

2014-01-29 D-Klotz

Какую дополнительную информацию я могу предоставить, чтобы помочь решить проблему? Спасибо. –

Ошибка входа # запроса для комбинации имени пользователя и пароля, поскольку агент определяет собственное определение Tomcat Realm (AmTomcatRealm) в файле server.xml. Область агента не использует комбинацию имени пользователя и пароля для проверки пользователей, так как учетные данные не должны присутствовать там (OpenAM выполняет аутентификацию, а впоследствии пароль давно ушел до того, как вы достигнете фактического защищенного приложения), это на самом деле немного беспокоит что у вас все еще есть доступ к паролю пользователя.

Поскольку агент никогда не должен знать пароль пользователя, он использует транспортную строку, содержащую несколько информации (среди идентификатора сеанса), имеет довольно недокументированный формат, вот некоторая ссылка на соответствующий исходный код: https://svn.forgerock.org/openam/trunk/openam-agents/jee-agents/jee-agents-sdk/src/main/java/com/sun/identity/agents/util/TransportToken.java

Кроме того, это не проблема с куриным яйцом, так как предполагается, что вход JAAS выполняется самим агентом, и на самом деле не ожидается, что приложение будет в первую очередь активировать логин. В настройках агента (и, конечно, в web.xml - см. Документацию к контейнеру) есть способы включить поддержку входа в систему JAAS, а затем агент может позаботиться об интеграции JAAS без необходимости знать что-либо о проприетарном формате транспортной строки.

источник

2014-02-03 13:23:15

Спасибо, что ответили. К сожалению, это тяжелый клиент java, который обращается к незащищенному сервлету для входа в систему. Приложение java имеет информацию о форме. Он отправляет имя пользователя и пароль сервлету. Сервлет использует java openam sdk для получения действительного токена SSO. Я надеялся каким-то образом заставить tomcat использовать httpservletrequest # login, чтобы сам tomcat знал об этом новом пользователе, но из того, что вы мне рассказываете, поскольку это приложение делает это за пределами коробки ... Возможно, я не могу этого сделать , –

Итак, я думаю, что реальный вопрос: как «СЛЕДУЕТ» java heavy client реализовать свой собственный вход в форму, так что мне не нужно использовать этот бэкдорный способ проверки пользователя на openAM? Да, есть SDK OpenAM Java (который я сейчас делаю в незащищенном сервлете), но как мне получить последующие вызовы сервлетов (которые все отправляют сериализованные java-объекты), чтобы узнать, кто этот пользователь и их существующие роли? –

В качестве побочного комментария: если я что-то пропустил, кажется, что OpenAM НЕ приспособлен к приложениям, которые отправляют сериализованные объекты в защищенные сервлеты.Я говорю об этом, потому что заметил, что когда я пытался защитить сервлет, фильтр openAM перенаправляет меня в скрытую форму с именем пользователя и паролем (это зашифрованная строка токена транспорта?). Это перенаправление отлично работает с браузерами, но прерывает любую попытку связывания объектов с защищенным сервлетом. –

В случае AgentRealm 'pass word 'не является паролем, а SSOTokenId из сеанса SSO.

источник

2014-01-31 08:28:02

Интересно. Так получилось, что у меня есть доступ к полной строке iPlanetDirectoryPro (я предполагаю, что это SSOTokenID). Поэтому я попробую это. Однако разве это не проблема курицы и яйца? Если я понимаю это правильно, я не могу обратиться к запросу сервлета и использовать #login (user, pass), ЕСЛИ я уже не аутентифицировал пользователя с помощью другого механизма. Правильно ли я понимаю? –

К сожалению, это не сработало. Я попытался использовать длинный идентификатор сеанса SSO. –

OpenAM/OpenSSO HttpServletRequest.login (пользователь, pass) терпит неудачу с «Недопустимая транспортная строка». Что это значит?

ответ

Смежные вопросы