gabbeer,

WAS по умолчанию кеширует данные авторизации, в том числе и членство в группах.

Таймаут кеша настраивается. Параметр Authentication cache timeout. . Значение по умолчанию 10 минут.
Справочник: Authentication mechanisms and expiration .

Еще можно через JACL принудительно почистить кеш :
Описание 1: Clearing WebSphere Security Cache
Описание 2: How to clear the WebSphere Application Server security cache

Mike KeyНе стал создавать ещё одну тему. Подскажите возможно ли настроить авторизацию в WAS 6.1(Win2K3) по домену, но работал чтобы от одного пользователя(как в IIS)

А что именно нужно получить на выходе?
Теоретически (т.к. сам не пробовал) варианты такие:
1. Как уже сказали использовать Local OS User Registry, ОС должна быть в домене.
2. Использовать LDAP User Registry для доступа к MS Active Directory по протоколу LDAP.
3. Использовать SPNEGO для"прозрачной" авторизации Creating a single sign-on for HTTP requests using the SPNEGO TAI

Mike Key,

Не сказал бы что стало понятнее.

1. Сам WAS запускается как сервис, сервису пользователь прописывается стандартными для Windows средствами.
2. При обращении к внешним ресурсам (JDBC, JMS и т.д.) можно указать данные авторизации именно для этого ресурса. Тогда при обращении к этому ресурсу будут использованы эти данные авторизации.
3. Для авторизации пользователей в приложениях (в том числе и в админ.консоли) как раз и используется реестр пользователей. Если использовать SPNEGO, то пользователь, который авторизовался в домене, при обращении к приложению из браузера, будет автоматически авторизован в этом приложении (т.е. ему не придется вводить логин/пароль еще раз). От браузера требуется поддержка такого метода авторизации. Подробнее читать документ по ссылке. Сам такого не настраивал, поэтому сказать насколько это работает не могу.
4. Если в приложении не указано, что для доступа к нему (или к его части) нужна авторизация, то соответственно и запрос на авторизацию выдаваться не будет (как раз анонимный доступ к приложению).

Mike Key,

Какие именно операции имеются в виду?

Все что происходит внутри J2EE приложения описано в разделе Security в J2EE Tutorial например.
В зависимости от того, о каких операциях идет речь, есть разные варианты.
Если речь идет именно о веб-приложении, то если доступ к ресурсу веб-приложения (URL-маска) защищен, то будет выдано предложение авторизоваться. Дальнейший доступ к ресурсам этого-же приложения будет происходить под указанным логином. Но вот обращение к внешним (по отношению к веб-приложению) ресурсам (EJB, сервисы, файлы и т.п.) может происходить с другими данными авторизации. Смотрите что такое RunAs в разделе J2EE Security.
Например здесь Propagating Security Identity или здесь Configuring a Component’s Propagated Security Identity

Постановка задачи на самом деле непонятна.
Если пользователя нужно авторизовать для доступа к веб-приложению, то зачем в дальнейшем анонимизировать доступ в пределах этого же сервера приложений? Смысл этого действия?

Mike KeyСмысл в том, чтобы ограничить доступ к приложению только для конкретных учётных записей домена. Поскольку учётки привязаны к определённому рабочему месту, приходится вводить в работу одного локального пользователя на сервере от которого непосредственно и будет работать приложение.
Приложение работает внутри J2EE сервера приложений.
С точки зрения ОС есть процесс сервера приложений, который запущен от определенного пользователя ОС. Если будут обращения к файловой системе например, они будут происходить от имени пользователя сервиса.
А почти все операции по авторизации внутри сервера приложений не видны с точки зрения операционной системы, т.е. выполняются на уровне Java.
Поэтому в общем случае ОС не будет знать от кого работает конкретное J2EE-приложение внутри сервера приложений, ибо для ОС отдельное J2EE-приложение просто не существует. ОС видит сервер приложений в целом.

Mike KeyТак и делал с самого начала. но политика безопасности мешает. в виндовском журнале пишет, что пользователю не разрешено логиниться на данную станцию бла бла бла
Попробуйте настроить WAS для работы с MS Active Directory по протоколу LDAP.
Сейчас у вас настроено через Local OS, в этом случае WAS обращается к средствам ОС для авторизации, что и приводит к этой ошибке.