У меня есть веб-приложение A, в котором пользователь должен пройти аутентификацию с помощью метода имени пользователя / передачи (https: //server.local/webappA). Устанавливается безопасное соединение (HTTPS) с сервером A.
Затем этим ребятам нужен какой-то «обман», чтобы использовать этого же аутентифицированного пользователя для открытия другого URL-адреса (https: //server.local: 8080 / webappB /? param1 = PID) и убедитесь, что аутентификация не нарушена. Другими словами, они не хотят, чтобы пользователь снова вводил свои учетные данные для webappB. Кроме того, этот новый webappB не должен быть доступен для пользователей, не прошедших аутентификацию.
WebappB работает в Tomcat и может быть размещен на том же сервере на другом порту #. Наша работа могла бы быть намного проще, если бы у webappA была хорошо известная система аутентификации, такая как LDAP, но ее нет. WebappA от компании A, а WebappB от компании B.
Есть ли возможность, что это сработает? Я лично не понимаю, как это сделать, поэтому я могу попробовать с вами, ребята. Я могу установить любой мод apache или сервер, который мне нужен.
Это не слишком сложно, если предположить, что оба приложения могут получить доступ к аналогичным данным сеанса. Но только если вы можете немного повозиться с кодом. Поскольку вы говорите о разных компаниях, предоставляющих программное обеспечение, вторая часть может оказаться невозможной.
Обычно, когда сеанс начинается с AppA имя пользователя / пароль проверяется по какому-либо источнику (будь то база данных, сервер IMAP, сервер LDAP и т. д.), на самом деле это не важная часть процесса. После этого первого сбора имени пользователя / пароля сеанс жетон выпущен. AppA проверяет сеанс жетон при доступе и если он действителен; загружает сеанс (поэтому он не требует имени пользователя и пароля каждый раз, когда вы что-то делаете).
Для этого вам нужно AppB к (а) иметь доступ к этой сессии жетон (достаточно просто, скорее всего, хранится как файл cookie), (б) получить доступ к данным сеанса, в которых перечислены действительные токены и связанные с пользователем (если пользователь не включен с токеном в cookie) и (c) создать сеанс в AppB без запуска имени пользователя / пароля или проверки существующего сеанса.
Доступ к токену сеанса:
Это должно быть просто вопросом чтения файлов cookie, предоставленных AppB. Так долго как AppA выдает файл cookie без ограничения path значение (низкий риск, поскольку компания A не может знать все папки, AppA мог работать под).
Доступ к данным сеанса:
Обычно приложение хранит информацию о сеансе в какой-то таблице базы данных. Единственный трюк может заключаться в том, чтобы узнать имя пользователя, связанное с сеансом (токен может включать имя пользователя или какой-либо идентификатор, либо ни то, ни другое). Срок действия сеанса определяется AppA должен подчиняться AppB
Создать сеанс AppB:
Наверное, самая сложная часть, если AppB имеет инъекцию зависимости от модуля аутентификации (включая запуск сеанса, обнаружение сеанса и завершение сеанса), тогда это просто вопрос заставить приложение прочитать тот же токен сеанса, что и AppA, сравните / подтвердите данные сеанса и при необходимости преобразуйте и расширите. Заметка если оба приложения не изменены, вы также захотите AppB отложить вход и, возможно, выход из системы AppA
Безопасность:
Если AppA использует файл cookie для хранения / извлечения информации о сеансе без указания значения пути, что любая другая часть того же веб-сайта также может видеть этот файл cookie. Если часть сайта обслуживается под http - включая изображения, таблицы стилей и javascript - этот файл cookie сеанса будет открыт и доступен для прослушивания программного обеспечения (например, firesheep) или оборудования. Обслуживание статического контента с другого сервера (или того же сервера под другим именем) помогает смягчить это.