Как я понимаю: по умолчанию в XP веб-сервис работает под пользователем ASPNET. Вот у меня есть веб-сервис, который должен копировать файлы, а также удалять файлы. С копированием проблем не возникает, а вот с удалением всё не так просто: если файлы создавались из под вебсервиса, то их удалить можно, ну а если из под какого-то другого пользователя, тогда возникает исключение access is denied. Каким образом решить данную проблему? Не красиво было бы давать ASPNET пользователю слишком много прав, мало ли...

Hello, "SpeedLover"
> Как я понимаю: по умолчанию в XP веб-сервис работает под пользователем
> ASPNET. Вот у меня есть веб-сервис, который должен копировать файлы, а
> также удалять файлы. С копированием проблем не возникает, а вот с
> удалением всё не так просто: если файлы создавались из под вебсервиса, то
> их удалить можно, ну а если из под какого-то другого пользователя, тогда
> возникает исключение access is denied. Каким образом решить данную
> проблему? Не красиво было бы давать ASPNET пользователю слишком много
> прав, мало ли...

Запустите веб сервис под пользователем отличным от ASPNET

Здравствуйте, SpeedLover, Вы писали:

SL>Как я понимаю: по умолчанию в XP веб-сервис работает под пользователем ASPNET. Вот у меня есть веб-сервис, который должен копировать файлы, а также удалять файлы. С копированием проблем не возникает, а вот с удалением всё не так просто: если файлы создавались из под вебсервиса, то их удалить можно, ну а если из под какого-то другого пользователя, тогда возникает исключение access is denied. Каким образом решить данную проблему? Не красиво было бы давать ASPNET пользователю слишком много прав, мало ли...
Для решения подобных проблем в ASP.NET существует имперсонация. Управляется тэгом <identity> в web.config. По умолчанию она выключена (поэтому и исполняется все от имени ASPNET). Есть два способа имперсонации. Первый от имени одной конкретной учетной записи. Второй — от имени учетной записи клиента сделавшего запрос. Очень все доступно написано в MSDN

Здравствуйте, stump, Вы писали:

S>Для решения подобных проблем в ASP.NET существует имперсонация. Управляется тэгом <identity> в web.config. По умолчанию она выключена (поэтому и исполняется все от имени ASPNET). Есть два способа имперсонации. Первый от имени одной конкретной учетной записи. Второй — от имени учетной записи клиента сделавшего запрос. Очень все доступно написано в MSDN

Значит так, у меня по умолчанию <identity impersonate="false"/> и используется ASPNET пользователь и права у него обрезаны. Пробую так <identity impersonate="true"/>, то в данном случае будет использоваться пользователь с под которого запущен сервис, то есть IUSR_WS25. Если сделаю так <identity impersonate="true" userName="domain\me" password="my_password" />, то при обращении к веб-сервисам будет использоваться моя учётная запись (администратор)? Если да, то третий вариант как бы подходит, но стоит ли давать так много прав веб-сервисам? Можно было бы и пользователя ASPNET добавить в группу админов и все проблемы зразу ж б решились. Тут хочется всего навсего дать возможность веб-сервисам удалять файлы и копировать и не больше...
Может я в чём-то ошибаюсь или не так понимаю?

Здравствуйте, SpeedLover, Вы писали:

SL>Здравствуйте, stump, Вы писали:

S>>Для решения подобных проблем в ASP.NET существует имперсонация. Управляется тэгом <identity> в web.config. По умолчанию она выключена (поэтому и исполняется все от имени ASPNET). Есть два способа имперсонации. Первый от имени одной конкретной учетной записи. Второй — от имени учетной записи клиента сделавшего запрос. Очень все доступно написано в MSDN

SL>Значит так, у меня по умолчанию <identity impersonate="false"/> и используется ASPNET пользователь и права у него обрезаны. Пробую так <identity impersonate="true"/>, то в данном случае будет использоваться пользователь с под которого запущен сервис, то есть IUSR_WS25. Если сделаю так <identity impersonate="true" userName="domain\me" password="my_password" />, то при обращении к веб-сервисам будет использоваться моя учётная запись (администратор)? Если да, то третий вариант как бы подходит, но стоит ли давать так много прав веб-сервисам? Можно было бы и пользователя ASPNET добавить в группу админов и все проблемы зразу ж б решились. Тут хочется всего навсего дать возможность веб-сервисам удалять файлы и копировать и не больше...
SL>Может я в чём-то ошибаюсь или не так понимаю?
Нет. Все не так.
<identity impersonate="false"/> — используется ASPNET или LocalSystem (в зависимости от настройки в machine.config)
<identity impersonate="true"/> — используется IUSR_xx если разрешен анонимный доступ, а если анонимный доступ запрещен то используется учетная запись клиента вызвавшего сервис.
<identity impersonate="true" userName="domain\me" password="my_password" /> — используется учетная запись "domain\me" (не обязательно доменная, может быть локальная)
В чем отличие первого варианта от третьего? В первом варианте одна учетка (ASPNET) используется для всех web приложений на сервере и если ты повышаешь ей привелегии, то эти привелегии становятся доступны всем приложениям на этом сервере.
В третьем случае ты настраиваешь учетную запись для конкретного web приложения и повышаешь полномочия для конкретного приложения.
Во втором случае, права будут зависеть от того, кто вызвал сервис. Т.е. один пользователь сможет записывать файлы с помощью web сервиса, а другой получит ошибку. Все зависит от прав конкретного пользователя вызвавшего сервис.
Выбирай что тебе лучше подходит.

Здравствуйте, stump, Вы писали:
S>Нет. Все не так.
S><identity impersonate="false"/> — используется ASPNET или LocalSystem (в зависимости от настройки в machine.config)
S><identity impersonate="true"/> — используется IUSR_xx если разрешен анонимный доступ, а если анонимный доступ запрещен то используется учетная запись клиента вызвавшего сервис.
S><identity impersonate="true" userName="domain\me" password="my_password" /> — используется учетная запись "domain\me" (не обязательно доменная, может быть локальная)
S>В чем отличие первого варианта от третьего? В первом варианте одна учетка (ASPNET) используется для всех web приложений на сервере и если ты повышаешь ей привелегии, то эти привелегии становятся доступны всем приложениям на этом сервере.
Замечу, что начиная с IIS 6.0 это не совсем так. В нем (если не включен старый режим изоляции) приложения живут в пулах, и для каждого пула можно указать identity независимо. По умолчанию ASP.NET будет работать под Network Service, а не ASP.NET. Можно поместить свое приложение в отдельный пул, и запустить его под идентити произвольного пользователя — эффект будет тот же, как от твоего третьего варианта.

S>В третьем случае ты настраиваешь учетную запись для конкретного web приложения и повышаешь полномочия для конкретного приложения.
S>Во втором случае, права будут зависеть от того, кто вызвал сервис. Т.е. один пользователь сможет записывать файлы с помощью web сервиса, а другой получит ошибку. Все зависит от прав конкретного пользователя вызвавшего сервис.
S>Выбирай что тебе лучше подходит.

Здравствуйте, Sinclair, Вы писали:


S>Замечу, что начиная с IIS 6.0 это не совсем так. В нем (если не включен старый режим изоляции) приложения живут в пулах, и для каждого пула можно указать identity независимо. По умолчанию ASP.NET будет работать под Network Service, а не ASP.NET. Можно поместить свое приложение в отдельный пул, и запустить его под идентити произвольного пользователя — эффект будет тот же, как от твоего третьего варианта.

Абсолютно согласен. Только в начальном посте речь шла про XP и IIS 5.1. В этом контексте я и описываю ситуацию.
Вообще для IIS 6.0 актуален случай ><identity impersonate="true"/>. Остальные обеспечиваются пулом приложений.

Здравствуйте, stump, Вы писали:

S>Нет. Все не так.
S><identity impersonate="false"/> — используется ASPNET или LocalSystem (в зависимости от настройки в machine.config)
S><identity impersonate="true"/> — используется IUSR_xx если разрешен анонимный доступ, а если анонимный доступ запрещен то используется учетная запись клиента вызвавшего сервис.
S><identity impersonate="true" userName="domain\me" password="my_password" /> — используется учетная запись "domain\me" (не обязательно доменная, может быть локальная)
S>В чем отличие первого варианта от третьего? В первом варианте одна учетка (ASPNET) используется для всех web приложений на сервере и если ты повышаешь ей привелегии, то эти привелегии становятся доступны всем приложениям на этом сервере.
S>В третьем случае ты настраиваешь учетную запись для конкретного web приложения и повышаешь полномочия для конкретного приложения.
S>Во втором случае, права будут зависеть от того, кто вызвал сервис. Т.е. один пользователь сможет записывать файлы с помощью web сервиса, а другой получит ошибку. Все зависит от прав конкретного пользователя вызвавшего сервис.
S>Выбирай что тебе лучше подходит.

В теории кажется всё понятно, но вот на практике не всё так просто.
Делаю следующее:
1. В настройках веб-приложения убираю галочку анонимного доступа.
2. Прописываю <identity impersonate="true"/>, то есть хочу использовать учётную запись клиента, вызвавшего какой-то сервис.
3. Вызываю сервис и получаю Unauthorized.

Вопрос: как происходит проверка учётной записи пользователя? Какие флаги должны быть установлены в настройках веб-приложения связанные с аутентификацией?

Здравствуйте, SpeedLover, Вы писали:


SL>В теории кажется всё понятно, но вот на практике не всё так просто.
SL>Делаю следующее:
SL>1. В настройках веб-приложения убираю галочку анонимного доступа.
SL>2. Прописываю <identity impersonate="true"/>, то есть хочу использовать учётную запись клиента, вызвавшего какой-то сервис.
SL>3. Вызываю сервис и получаю Unauthorized.
Замечательно! Это говорит о том что все идет по плану!
Теперь надо передать данные учетной записи с клиента. Передаются они с всойстве Credentials клиентсткого прокси класса сервиса, за что некоторые ушлые программеры называют их "кредами"

service.Credentials = System.Net.CredentialCache.DefaultCredentials;

SL>Вопрос: как происходит проверка учётной записи пользователя? Какие флаги должны быть установлены в настройках веб-приложения связанные с аутентификацией?

Надо чтоб был выставлен флаг "Integrated windows authentication". Флаг "Anonymous access" можно снять а можно придушить его в web конфиге. Рассказывать как?

Здравствуйте, stump, Вы писали:

S>Здравствуйте, SpeedLover, Вы писали:


SL>>В теории кажется всё понятно, но вот на практике не всё так просто.
SL>>Делаю следующее:
SL>>1. В настройках веб-приложения убираю галочку анонимного доступа.
SL>>2. Прописываю <identity impersonate="true"/>, то есть хочу использовать учётную запись клиента, вызвавшего какой-то сервис.
SL>>3. Вызываю сервис и получаю Unauthorized.
S>Замечательно! Это говорит о том что все идет по плану!
S>Теперь надо передать данные учетной записи с клиента. Передаются они с всойстве Credentials клиентсткого прокси класса сервиса, за что некоторые ушлые программеры называют их "кредами"
S>

S>service.Credentials = System.Net.CredentialCache.DefaultCredentials; 
S>

SL>>Вопрос: как происходит проверка учётной записи пользователя? Какие флаги должны быть установлены в настройках веб-приложения связанные с аутентификацией?

S>Надо чтоб был выставлен флаг "Integrated windows authentication". Флаг "Anonymous access" можно снять а можно придушить его в web конфиге. Рассказывать как?
Ну расскажи, познавание нового никогда не мешало.
А я тем временем попробую реализовать передачу данных учётной записи.

Здравствуйте, SpeedLover, Вы писали:


S>>Надо чтоб был выставлен флаг "Integrated windows authentication". Флаг "Anonymous access" можно снять а можно придушить его в web конфиге. Рассказывать как?
SL>Ну расскажи, познавание нового никогда не мешало.
SL>А я тем временем попробую реализовать передачу данных учётной записи.
Это вопрос из FAQ-а. В web.config пишешь:

<authorization>
 <deny users="?" /> 
</authorization>

Будет заворачивать анонимов независимо от состояния флажка "Anonymous access" в настройках web directory

Здравствуйте, stump, Вы писали:

S>Здравствуйте, SpeedLover, Вы писали:


S>>>Надо чтоб был выставлен флаг "Integrated windows authentication". Флаг "Anonymous access" можно снять а можно придушить его в web конфиге. Рассказывать как?
SL>>Ну расскажи, познавание нового никогда не мешало.
SL>>А я тем временем попробую реализовать передачу данных учётной записи.
S>Это вопрос из FAQ-а. В web.config пишешь:
S>

S><authorization>
S> <deny users="?" />
S></authorization>
S>

S>Будет заворачивать анонимов независимо от состояния флажка "Anonymous access" в настройках web directory

Спасибо!
И так, у меня практически всё получилось, но есть ещё такая ситуация: захожу я под локальной записью (администратор) всё работает нормально, при запросе веб-сервиса через броузер выпадает окно, где ввожу имя, пароль и в ответ получаю список функций. Доступ есть — это хорошо. Другая ситуция возникает, когда я пытаюсь ввойти под удаллённой записью (админ): всё так же получаю Unauthorized. С чем это может быть связано?

Здравствуйте, SpeedLover, Вы писали:

SL>Здравствуйте, stump, Вы писали:

S>>Здравствуйте, SpeedLover, Вы писали:
SL>И так, у меня практически всё получилось, но есть ещё такая ситуация: захожу я под локальной записью (администратор) всё работает нормально, при запросе веб-сервиса через броузер выпадает окно, где ввожу имя, пароль и в ответ получаю список функций. Доступ есть — это хорошо. Другая ситуция возникает, когда я пытаюсь ввойти под удаллённой записью (админ): всё так же получаю Unauthorized. С чем это может быть связано?
Имя домена надо указывать.