Здравствуйте.  У меня будет несколько web-приложений. В них требуется авторизация (сейчас есть одно, буду писать второе). Авторизация проходит через куки, посылаю несколько куков браузеру name,surname,operator_id. Потом уже с ними работаю в приложение. Сейчас пишу второе приложение, и хочу сделать чтоб авторизация была общая для всех, как это можно сделать?

Не очень понятно

1. Речь идет об авторизации или об аутентификации

2. Почему для идентификации не использовать имя пользователя и стандартный ID, созданный в рамках сеанса и засылаемый клиенту контейнером.

3. Хранить в базе данных имя и пароль. 

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

То есть вам требуется "сквозная" аутентификация. Аутентифицировался в одном приложении, работаешь автоматом и во втором?
То есть требуется хранить в одном месте аутентификацию всех пользователей двух приложений.

1. Если в качестве базы данных используется Oracke, я бы использовал FGA, поскольку здесь в оперативной памяти создается виртуальная база с информацией или информацию "окружающей среды", получаемую с помощью функции SYS_CONTEXT. В этом "ящике" в памяти базы и можно хранить информацию аутентификации всех пользователей и сверять ее с пришедшими куки. А в момент, когда сеанс становится инвалидным надо просто информацию в виртуальной базе убивать.

2. В Tomcat, например, сколько я помню, можно из одного приложения получить доступ к контексту другого приложения (контексту сервлета).  К сожалению, под рукой сейчас нет документации, а на память не помню.
Однако точно читал, что можно. Храните информацию аутентификации в контексте сервлета одного приложения и копируйте в контекст другого в момент первого прихода пользователя..  А в момент, когда сеанс становится инвалидным надо просто информацию в контексте приложения удалить, а на это действо навесить Listener, который удалит информацию из другого контекста, а там должен быть Listener, который  "инвалидирует" и второй сеанс. То есть механизм должен быть симметричным.

И еще, атрибут элементов <Context> и <DefaultContext>:

crossContext - Устанавливать значения true следует в том случае, когда необходимо, чтобы в данном приложении при вызове ServletContext.getContext() благополучно возвращалась ссылка на диспетчер запросов для другого web приложения выполняющегося в рамках данного виртуального хоста. Установка значения false (по умолчанию) в целях обеспечения безопасности окружения приводит к тому, что вызов getContext() всегда будет возвращать null.

Указать, чтобы Cookie приходили на некоторый домен можно с помощью метода: 
 
public void setDomain(String pattern);

This method sets the domain attribute of the cookie. This attribute defines which
hosts the cookie should be presented to by the client. A domain begins with a dot
(.foo.com) and means that hosts in that DNS zone (www.foo.com but not
a.b.foo.com) should see the cookie. By default, cookies are only returned to the
host which saved them.
See RFC 2109 for a more complete discussion of domains and cookies.

Добавлено через 2 минуты и 12 секунд
Указать, чтобы Cookie приходили на некоторый путь можно с помощью методf:

public void setPath(String uri);

This method sets the path attribute of the cookie. The client should only return
cookies to paths that begin with the given path string.

Спасибо!! Сейчас смотрю похоже то что мне надо! )