Existe uma maneira de restringir o acesso a um ASMX Webservice, ou seja, a página asmx e seu WSDL?

Question

Eu tenho um C # .net webservice que eu preciso para restringir o acesso. Eu já exigem meus consumidores a usar um nome de usuário e senha para chamar o serviço. Mas, há uma maneira de restringir o acesso à página asmx real ea WSDL? Eu precisaria para restringir o acesso ao webservice por nome de usuário / senha e endereço IP. Se um usuário não tem as credenciais corretas, eu não quero que eles saibam que existem webmethods no webservice.

Isso pode ser feito embora IIS? Eu sei que eu posso restringir os endereços IP através do IIS, mas eu posso também usar nomes de usuário / senhas?

Existe alguma outra maneira de fazer isso fora do IIS, talvez usando C # .net?

Answer 1

Bem, já que é ASMX você tem toda a pilha de execução ASP.NET à sua disposição.

Etapa # 1 - gerir o recurso através .config

Aplique uma tag <location> para os recursos que você quer garantidos. Assumindo que é um único arquivo ASMX você pode simplesmente fazer o seguinte em seu web.config:

<location path="MyWebService.asmx">
    <system.web>
        <!-- resource specific options will go here -->
    </system.web>
</location>

Etapa # 2 - autenticação de seus usuários

Você precisa decidir como você está realmente indo para autenticar os usuários. Existem várias maneiras de fazer isso e vários padrões de autenticação você pode alavancar. Você precisa escolher a abordagem que é o ajuste certo para você.

Se você estiver em uma intranet e estão usando autenticação do Windows eu sugiro alavancar isso porque é realmente a opção mais simples para começar a instalação. No entanto, se os seus serviços são acessados ??através da internet, em seguida, o Windows authenticatio não é realmente uma opção e você precisa escolher a partir de um padrão web. A mais simples delas é autenticação básica , mas você deve única usar este sobre SSL uma vez que o nome de usuário / senha não são criptografados (somente base64 codificado). O próximo passo a partir de que é Digest autenticação que não exige SSL porque o nome de usuário / senha são enviado com um hash MD5. Para o máximo que você pode ir com SSL v3 onde você emitir um certificado de cliente específico para cada usuário do seu API.

Agora, qual opção você selecionar para ditames de segurança que as necessidades mais a ser feito. Se você escolher a segurança do Windows, é tão fácil quanto adicionar o seguinte elemento ao elemento <system.web> começamos com na Etapa # 1:

<authentication mode="Windows" />

O restante dos protocolos de segurança vão exigir um pouco mais de trabalho. O ASP.NET não fornece suporte intrínseco para Basic, Digest ou SSL v3. Tecnicamente, você pode aproveitar o IIS para fazer este tipo de autenticação para você, mas ele sempre vai para mapear para um usuário do Windows. Se isso é uma opção para você, então simplesmente deixar o elemento <authentication mode="Windows" /> e configurar o IIS em conformidade. Se, no entanto, que não é uma opção, ou porque você simplesmente não tem controle sobre IIS / ActiveDirectory ou você precisa autenticar em um banco de dados de usuário personalizada, então isso significa que você precisa para ligar um costume HttpModule para fornecer suporte para estes segurança protocolos.

Etapa # 3 - garantir o recurso

A abordagem mais simples para garantir o recurso é basicamente dizer: "não deixe ninguém que não tenha autenticado com êxito, de alguma forma este recurso". Isso é feito usando a seguinte configuração autorização:

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

Se você quiser permitir que apenas certeza usuários que você pode mudar para fazer o seguinte em vez disso:

<authorization>
    <deny users="*" />
    <allow users="jdoe, msmith" />
</authorization>

Outra abordagem é definir as funções (grupos) e simplesmente bloquear o recurso para baixo para um papel especial que você colocar os usuários que você deseja para acessar o recurso em.

<authorization>
    <deny users="*" />
    <allow roles="My Service Users" />
</authorization>

Isso mapeia bem para a autenticação do Windows porque você só pode configurar um grupo e Windows deixar sua equipe MIS controlar quais usuários estão nesse grupo usando ActiveDirectory. No entanto, o recurso também funciona muito bem para a autenticação não-Windows assumindo a implementação de segurança que você usou papéis expõe através de sua implementação IPrincipal.

Answer 2

Duas opções: Criar um site totalmente diferente em uma porta diferente com bloqueados permissões. Isto tem a vantagem de fornecer uma certa quantidade de "segurança pela obscuridade" (meio brincando ...) Ou você pode adicionar um novo aplicativo em seu site (mesma porta, caminho diferente), em um pool de aplicativo diferente e permissões atribuir esse caminho.

Em ambos os casos, o serviço web não vai ser capaz de falar com as várias "coisas" ASP.NET como o objeto do aplicativo (bem ele vai, mas não vai ser a mesma). A implantação é apenas ligeiramente mais difícil:. Implantar os mesmos binários, mas apenas incluir o arquivo de um serviço web

Answer 3

Você pode autenticar usando um HttpModule. SSL + BasicAuthentication deve render o melhor interoperabilidade com outras cadeias de ferramentas.

No HttpModule, você tem acesso ao pedido e pode negar usuários não autenticados acesso a solicitações apenas .asmx. E mesmo assim você pode deixá-los acessar o WSDL.

Answer 4

Add <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> para a seção <httpHandlers> do arquivo web.config

Answer 5

Eu não sei como prática isto é para você, mas você poderia considerar a atualização para o WCF. WCF é totalmente compatível com os serviços web ASMX, e permite-lhe controlar ou não o WSDL é exposta através da definição de um ponto de extremidade MEX (troca de metadados). endpoint não MEX, não WSDL.

Answer 6

Você pode parar de ser mostrado WSDL, removendo o protocolo da documentação do elemento em Machine.config

Update: autenticação Web Services - melhores práticas ? Se os usuários têm nomes de usuário / senhas você pode usar HTTP autenticação básica via HTTPS.

Você também pode implementá-lo de uma forma ligeiramente differnt. A primeira chamada para seu serviço web deve ser o método de autenticação. autentica clientes e recebe um token de autenticação. Esse token deve ser apresentado a todos os outros métodos expostos pelo seu serviço de web.