Quadro de Segurança: Gestão de Sessão

Produto/Serviço Artigo
Azure AD
Dispositivo IoT
Documento Azure DB
ADFS
Servidor de Identidade
Aplicação Web
API Web

Implementar o logout adequado utilizando métodos ADAL ao utilizar o Azure AD

Título Detalhes
Componente Azure AD
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências N/D
Passos Se a aplicação se basear no token de acesso emitido pela Azure AD, o manipulador de eventos logout deve ligar

Exemplo

HttpContext.GetOwinContext().Authentication.SignOut(OpenIdConnectAuthenticationDefaults.AuthenticationType, CookieAuthenticationDefaults.AuthenticationType)

Exemplo

Também deve destruir a sessão do utilizador chamando o método Session.Abandon(). O método seguinte mostra uma implementação segura do logout do utilizador:

    [HttpPost]
        [ValidateAntiForgeryToken]
        public void LogOff()
        {
            string userObjectID = ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value;
            AuthenticationContext authContext = new AuthenticationContext(Authority + TenantId, new NaiveSessionCache(userObjectID));
            authContext.TokenCache.Clear();
            Session.Clear();
            Session.Abandon();
            Response.SetCookie(new HttpCookie("ASP.NET_SessionId", string.Empty));
            HttpContext.GetOwinContext().Authentication.SignOut(
                OpenIdConnectAuthenticationDefaults.AuthenticationType,
                CookieAuthenticationDefaults.AuthenticationType);
        } 

Use vidas finitas para tokens SaS gerados

Título Detalhes
Componente Dispositivo IoT
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências N/D
Passos Os tokens SaS gerados para autenticação no Azure IoT Hub devem ter um período de validade finito. Mantenha as vidas simbólicas sas ao mínimo para limitar o tempo que podem ser reproduzidos no caso de as fichas estarem comprometidas.

Utilize as vidas mínimas simbólicas para tokens de recursos gerados

Título Detalhes
Componente Documento Azure DB
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências N/D
Passos Reduza o tempo de token de recurso para um valor mínimo necessário. As fichas de recursos têm um tempo de tempo válido de 1 hora.

Implementar o logout adequado utilizando métodos de S.A.

Título Detalhes
Componente ADFS
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências N/D
Passos Se a aplicação se basear no token STS emitido pela ADFS, o manipulador de eventos logout deve ligar para o método WSFederationAuthenticationModule.FederatedSignOut() para registar o utilizador. Também a sessão atual deve ser destruída, e o valor simbólico da sessão deve ser reposto e anulado.

Exemplo

        [HttpPost, ValidateAntiForgeryToken]
        [Authorization]
        public ActionResult SignOut(string redirectUrl)
        {
            if (!this.User.Identity.IsAuthenticated)
            {
                return this.View("LogOff", null);
            }

            // Removes the user profile.
            this.Session.Clear();
            this.Session.Abandon();
            HttpContext.Current.Response.Cookies.Add(new System.Web.HttpCookie("ASP.NET_SessionId", string.Empty)
                {
                    Expires = DateTime.Now.AddDays(-1D),
                    Secure = true,
                    HttpOnly = true
                });

            // Signs out at the specified security token service (STS) by using the WS-Federation protocol.
            Uri signOutUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Issuer);
            Uri replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm);
            if (!string.IsNullOrEmpty(redirectUrl))
            {
                replyUrl = new Uri(FederatedAuthentication.WSFederationAuthenticationModule.Realm + redirectUrl);
            }
           //     Signs out of the current session and raises the appropriate events.
            var authModule = FederatedAuthentication.WSFederationAuthenticationModule;
            authModule.SignOut(false);
        //     Signs out at the specified security token service (STS) by using the WS-Federation
        //     protocol.            
            WSFederationAuthenticationModule.FederatedSignOut(signOutUrl, replyUrl);
            return new RedirectResult(redirectUrl);
        }

Implemente o logout adequado ao utilizar o Servidor de Identidade

Título Detalhes
Componente Servidor de Identidade
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências Assinatura IdentitáriaServer3-Federada para fora
Passos O IdentityServer apoia a capacidade de federação com fornecedores de identidade externos. Quando um utilizador assina fora de um fornecedor de identidade a montante, dependendo do protocolo utilizado, pode ser possível receber uma notificação quando o utilizador assinar. Permite que o IdentityServer notifique os seus clientes para que também possam assinar o utilizador. Consulte a documentação na secção de referências para obter os detalhes da implementação.

As aplicações disponíveis em HTTPS devem utilizar cookies seguros

Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos EnvironmentType - OnPrem
Referências httpCookies Element (ASP.NET Definições Schema), HttpCookie.Secure Property
Passos Normalmente, os cookies só são acessíveis ao domínio para o qual foram examinados. Infelizmente, a definição de "domínio" não inclui o protocolo para que os cookies que são criados em HTTPS estejam acessíveis em HTTP. O atributo "seguro" indica ao navegador que o cookie só deve ser disponibilizado através do HTTPS. Certifique-se de que todos os cookies definidos em HTTPS utilizem o atributo secure . A exigência pode ser aplicada no ficheiro web.config, definindo o atributo requereSSL à verdadeira. É a abordagem preferida porque irá impor o atributo seguro para todos os cookies atuais e futuros sem a necessidade de fazer quaisquer alterações adicionais de código.

Exemplo

<configuration>
  <system.web>
    <httpCookies requireSSL="true"/>
  </system.web>
</configuration>

A definição é aplicada mesmo que HTTP seja utilizado para aceder à aplicação. Se HTTP for utilizado para aceder à aplicação, a configuração quebra a aplicação porque os cookies são definidos com o atributo seguro e o navegador não os enviará de volta para a aplicação.

Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Web Forms, MVC5
Atributos EnvironmentType - OnPrem
Referências N/D
Passos Quando a aplicação web é a Parte De Gestão, e o IdP é servidor ADFS, o atributo seguro do token da FedAuth pode ser configurado por definição requerSSL a True na system.identityModel.services secção de web.config:

Exemplo

  <system.identityModel.services>
    <federationConfiguration>
      <!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
      <cookieHandler requireSsl="true" persistentSessionLifetime="0.0:20:0" />
    ....  
    </federationConfiguration>
  </system.identityModel.services>
Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências Atributo de cookies seguros
Passos Para mitigar o risco de divulgação de informação com um ataque de scripts cross-site (XSS), um novo atributo - httpOnly - foi introduzido nos cookies e é suportado por todos os principais navegadores. O atributo especifica que um cookie não é acessível através do script. Ao utilizar cookies HttpOnly, uma aplicação web reduz a possibilidade de que informações sensíveis contidas no cookie possam ser roubadas através do script e enviadas para o site de um intruso.

Exemplo

Todas as aplicações baseadas em HTTP que utilizam cookies devem especificar httpOnly na definição de cookies, implementando a seguinte configuração em web.config:

<system.web>
.
.
   <httpCookies requireSSL="false" httpOnlyCookies="true"/>
.
.
</system.web>
Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Web Forms
Atributos N/D
Referências FormuláriosAufercation.requer propriedade de Sl
Passos O valor da propriedade RequireSSL é definido no ficheiro de configuração para uma aplicação ASP.NET utilizando o atributo requerESSL do elemento de configuração. Pode especificar no ficheiro Web.config para a sua aplicação ASP.NET se a Segurança da Camada de Transporte (TLS), anteriormente conhecida como SSL (Camada de Tomadas Seguras), é necessária para devolver o cookie de autenticação de formulários ao servidor, definindo o atributo requerendoSSL.

Exemplo

O exemplo de código a seguir define o atributo requereSSL no ficheiro Web.config.

<authentication mode="Forms">
  <forms loginUrl="member_login.aspx" cookieless="UseCookies" requireSSL="true"/>
</authentication>
Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis MVC5
Atributos EnvironmentType - OnPrem
Referências Configuração Windows Identity Foundation (WIF) – Parte II
Passos Para definir httpOn atribua para cookies FedAuth, o valor de atributo HideFromCsript deve ser definido para True.

Exemplo

A configuração seguinte mostra a configuração correta:

<federatedAuthentication>
<cookieHandler mode="Custom"
                       hideFromScript="true"
                       name="FedAuth"
                       path="/"
                       requireSsl="true"
                       persistentSessionLifetime="25">
</cookieHandler>
</federatedAuthentication>

Mitigar contra ataques de falsificação de pedidos de cross-site (CSRF) em páginas web ASP.NET

Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências N/D
Passos Falsificação de pedidos de sites (CSRF ou XSRF) é um tipo de ataque no qual um intruso pode realizar ações no contexto de segurança de uma sessão estabelecida de um utilizador diferente num site. O objetivo é modificar ou apagar conteúdo, se o site direcionado se basear exclusivamente em cookies de sessão para autenticar o pedido recebido. Um intruso poderia explorar esta vulnerabilidade obtendo um navegador de um utilizador diferente para carregar um URL com um comando a partir de um site vulnerável no qual o utilizador já está iniciado. Existem muitas formas de um intruso fazer isso, como por exemplo hospedar um site diferente que carrega um recurso a partir do servidor vulnerável, ou fazer com que o utilizador clique num link. O ataque pode ser evitado se o servidor enviar um sinal adicional ao cliente, requer que o cliente inclua esse token em todos os pedidos futuros, e verifica que todos os pedidos futuros incluem um token que diz respeito à sessão atual, como por exemplo, utilizando o ASP.NET AntiForgeryToken ou ViewState.
Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis MVC5, MVC6
Atributos N/D
Referências Prevenção XSRF/CSRF em ASP.NET MVC e Páginas Web
Passos Formulários anti-CSRF e ASP.NET MVC - Utilize o método de AntiForgeryToken ajuda em Vistas; coloque um Html.AntiForgeryToken() no formulário, por exemplo,

Exemplo

@using (Html.BeginForm("UserProfile", "SubmitUpdate")) { 
    @Html.ValidationSummary(true) 
    @Html.AntiForgeryToken()
    <fieldset> 

Exemplo

<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>

Exemplo

Ao mesmo tempo, html.AntiForgeryToken() dá ao visitante um cookie chamado __RequestVerificationToken, com o mesmo valor que o valor escondido aleatório acima indicado. Em seguida, para validar um post de formulário de entrada, adicione o filtro [ValidateAntiForgeryToken] ao método de ação alvo. Por exemplo:

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}

Filtro de autorização que verifica:

  • O pedido de entrada tem um cookie chamado __RequestVerificationToken
  • O pedido de entrada tem uma Request.Form entrada chamada __RequestVerificationToken
  • Estes cookies e Request.Form valores correspondem Assumindo que está tudo bem, o pedido passa normalmente. Mas se não, então uma falha de autorização com mensagem "Um sinal anti-falsificação exigido não foi fornecido ou foi inválido".

Exemplo

Anti-CSRF e AJAX: O token do formulário pode ser um problema para os pedidos do AJAX, porque um pedido do AJAX pode enviar dados de JSON, não dados de formulário HTML. Uma solução é enviar os tokens num cabeçalho HTTP personalizado. O código seguinte utiliza a sintaxe Razor para gerar os tokens e, em seguida, adiciona os tokens a um pedido do AJAX.

<script>
    @functions{
        public string TokenHeaderValue()
        {
            string cookieToken, formToken;
            AntiForgery.GetTokens(null, out cookieToken, out formToken);
            return cookieToken + ":" + formToken;                
        }
    }

    $.ajax("api/values", {
        type: "post",
        contentType: "application/json",
        data: {  }, // JSON data goes here
        dataType: "json",
        headers: {
            'RequestVerificationToken': '@TokenHeaderValue()'
        }
    });
</script>

Exemplo

Quando processar o pedido, extraia as fichas do cabeçalho do pedido. Em seguida, chame o método AntiForgery.Validate para validar os tokens. O método Valide abre uma exceção se as fichas não forem válidas.

void ValidateRequestHeader(HttpRequestMessage request)
{
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}
Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Web Forms
Atributos N/D
Referências Aproveite ASP.NET funcionalidades incorporadas para evitar ataques web
Passos Os ataques CSRF em aplicações baseadas no WebForm podem ser atenuados definindo o ViewStateUserKey para uma cadeia aleatória que varia para cada utilizador - ID do utilizador ou, melhor ainda, ID de sessão. Por uma série de razões técnicas e sociais, o ID da sessão é muito melhor porque um ID de sessão é imprevisível, horários e varia por utilizador.

Exemplo

Aqui está o código que precisa de ter em todas as suas páginas:

void Page_Init (object sender, EventArgs e) {
   ViewStateUserKey = Session.SessionID;
   :
}

Preparar sessão para a vida útil da inatividade

Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências HttpSessionState.Timeout Property
Passos O tempo limite de sessão representa o evento que ocorre quando um utilizador não realiza qualquer ação num web site durante um intervalo (definido pelo servidor web). O evento, no lado do servidor, altera o estado da sessão de utilizador para 'inválido' (por exemplo, "já não é utilizado") e instrui o servidor web a destruí-lo (eliminando todos os dados nele contidos). O seguinte exemplo de código define o atributo de sessão de tempo limite para 15 minutos no ficheiro Web.config.

Exemplo

<configuration>
  <system.web>
    <sessionState mode="InProc" cookieless="true" timeout="15" />
  </system.web>
</configuration>

Ativar a deteção de ameaças no Azure SQL

Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Web Forms
Atributos N/D
Referências Formulários elemento para autenticação (ASP.NET Definições Schema)
Passos Desata o intervalo de cookies do bilhete de autenticação formulário para 15 minutos

Exemplo

<forms  name=".ASPXAUTH" loginUrl="login.aspx"  defaultUrl="default.aspx" protection="All" timeout="15" path="/" requireSSL="true" slidingExpiration="true"/>
</forms>
Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Web Forms, MVC5
Atributos EnvironmentType - OnPrem
Referências asdeqa
Passos Quando a aplicação web é AParting e ADFS é o STS, a vida útil dos cookies de autenticação - fichas FedAuth - pode ser definida pela seguinte configuração em web.config:

Exemplo

  <system.identityModel.services>
    <federationConfiguration>
      <!-- Set requireSsl=true; domain=application domain name used by FedAuth cookies (Ex: .gdinfra.com); -->
      <cookieHandler requireSsl="true" persistentSessionLifetime="0.0:15:0" />
      <!-- Set requireHttps=true; -->
      <wsFederation passiveRedirectEnabled="true" issuer="http://localhost:39529/" realm="https://localhost:44302/" reply="https://localhost:44302/" requireHttps="true"/>
      <!--
      Use the code below to enable encryption-decryption of claims received from ADFS. Thumbprint value varies based on the certificate being used.
      <serviceCertificate>
        <certificateReference findValue="4FBBBA33A1D11A9022A5BF3492FF83320007686A" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
      </serviceCertificate>
      -->
    </federationConfiguration>
  </system.identityModel.services>

Exemplo

Também o ADFS emitiu a vida útil do token da SAML em 15 minutos, executando o seguinte comando de powershell no servidor ADFS:

Set-ADFSRelyingPartyTrust -TargetName "<RelyingPartyWebApp>" -ClaimsProviderName @("Active Directory") -TokenLifetime 15 -AlwaysRequireAuthentication $true

Implementar o logout adequado a partir da aplicação

Título Detalhes
Componente Aplicação Web
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências N/D
Passos Execute a assinatura adequada da aplicação, quando o utilizador premir o botão 'iniciar sessão'. Após o logout, a aplicação deve destruir a sessão do utilizador e também redefinir e anular o valor dos cookies da sessão, juntamente com a reposição e anulação do valor dos cookies de autenticação. Além disso, quando várias sessões estão ligadas a uma única identidade de utilizador, devem ser encerradas coletivamente no lado do servidor no tempo limite ou logout. Por último, certifique-se de que a funcionalidade Logout está disponível em todas as páginas.

Mitigar contra ataques de falsificação de pedidos de cross-site (CSRF) em APIs web ASP.NET

Título Detalhes
Componente API Web
Fase SDL Compilação
Tecnologias aplicáveis Genérica
Atributos N/D
Referências N/D
Passos Falsificação de pedidos de sites (CSRF ou XSRF) é um tipo de ataque no qual um intruso pode realizar ações no contexto de segurança de uma sessão estabelecida de um utilizador diferente num site. O objetivo é modificar ou apagar conteúdo, se o site direcionado se basear exclusivamente em cookies de sessão para autenticar o pedido recebido. Um intruso poderia explorar esta vulnerabilidade obtendo um navegador de um utilizador diferente para carregar um URL com um comando a partir de um site vulnerável no qual o utilizador já está iniciado. Existem muitas formas de um intruso fazer isso, como por exemplo hospedar um site diferente que carrega um recurso a partir do servidor vulnerável, ou fazer com que o utilizador clique num link. O ataque pode ser evitado se o servidor enviar um sinal adicional ao cliente, requer que o cliente inclua esse token em todos os pedidos futuros, e verifica que todos os pedidos futuros incluem um token que diz respeito à sessão atual, como por exemplo, utilizando o ASP.NET AntiForgeryToken ou ViewState.
Título Detalhes
Componente API Web
Fase SDL Compilação
Tecnologias aplicáveis MVC5, MVC6
Atributos N/D
Referências Prevenção de ataques de falsificação de pedidos de transcom site (CSRF) em ASP.NET API web
Passos Anti-CSRF e AJAX: O token do formulário pode ser um problema para os pedidos do AJAX, porque um pedido do AJAX pode enviar dados de JSON, não dados de formulário HTML. Uma solução é enviar os tokens num cabeçalho HTTP personalizado. O código seguinte utiliza a sintaxe Razor para gerar os tokens e, em seguida, adiciona os tokens a um pedido do AJAX.

Exemplo

<script>
    @functions{
        public string TokenHeaderValue()
        {
            string cookieToken, formToken;
            AntiForgery.GetTokens(null, out cookieToken, out formToken);
            return cookieToken + ":" + formToken;                
        }
    }
    $.ajax("api/values", {
        type: "post",
        contentType: "application/json",
        data: {  }, // JSON data goes here
        dataType: "json",
        headers: {
            'RequestVerificationToken': '@TokenHeaderValue()'
        }
    });
</script>

Exemplo

Quando processar o pedido, extraia as fichas do cabeçalho do pedido. Em seguida, chame o método AntiForgery.Validate para validar os tokens. O método Valide abre uma exceção se as fichas não forem válidas.

void ValidateRequestHeader(HttpRequestMessage request)
{
    string cookieToken = "";
    string formToken = "";

    IEnumerable<string> tokenHeaders;
    if (request.Headers.TryGetValues("RequestVerificationToken", out tokenHeaders))
    {
        string[] tokens = tokenHeaders.First().Split(':');
        if (tokens.Length == 2)
        {
            cookieToken = tokens[0].Trim();
            formToken = tokens[1].Trim();
        }
    }
    AntiForgery.Validate(cookieToken, formToken);
}

Exemplo

Formulários anti-CSRF e MVC ASP.NET - Utilize o método de ajuda AntiForgeryToken em Vistas; coloque um Html.AntiForgeryToken na forma, por exemplo,

@using (Html.BeginForm("UserProfile", "SubmitUpdate")) { 
    @Html.ValidationSummary(true) 
    @Html.AntiForgeryToken()
    <fieldset> 
}

Exemplo

O exemplo acima irá dar produção como o seguinte:

<form action="/UserProfile/SubmitUpdate" method="post">
    <input name="__RequestVerificationToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
    <!-- rest of form goes here -->
</form>

Exemplo

Ao mesmo tempo, html.AntiForgeryToken() dá ao visitante um cookie chamado __RequestVerificationToken, com o mesmo valor que o valor escondido aleatório acima indicado. Em seguida, para validar um post de formulário de entrada, adicione o filtro [ValidateAntiForgeryToken] ao método de ação alvo. Por exemplo:

[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc.
}

Filtro de autorização que verifica:

  • O pedido de entrada tem um cookie chamado __RequestVerificationToken
  • O pedido de entrada tem uma Request.Form entrada chamada __RequestVerificationToken
  • Estes cookies e Request.Form valores correspondem Assumindo que está tudo bem, o pedido passa normalmente. Mas se não, então uma falha de autorização com mensagem "Um sinal anti-falsificação exigido não foi fornecido ou foi inválido".
Título Detalhes
Componente API Web
Fase SDL Compilação
Tecnologias aplicáveis MVC5, MVC6
Atributos Fornecedor de identidade - ADFS, Fornecedor de Identidade - Azure Ad
Referências Proteja uma API Web com Contas Individuais e Login Local em ASP.NET Web API 2.2
Passos Se a API Web for protegida usando o OAuth 2.0, então espera um sinal ao portador no cabeçalho de pedido de autorização e concede acesso ao pedido apenas se o token for válido. Ao contrário da autenticação baseada em cookies, os navegadores não anexam as fichas do portador aos pedidos. O cliente que solicita precisa de anexar explicitamente o sinal do portador no cabeçalho do pedido. Portanto, para ASP.NET APIs Web protegidos usando OAuth 2.0, os tokens portadores são considerados como uma defesa contra os ataques de CSRF. Por favor, note que se a parte MVC da aplicação utiliza a autenticação de formulários (isto é, utiliza cookies), as fichas anti-falsificação têm de ser utilizadas pela aplicação web MVC.

Exemplo

A API Web tem de ser informada para se basear apenas em fichas ao portador e não em cookies. Pode ser feito pela seguinte configuração em WebApiConfig.Register método:

config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));

O método SupressefaultHostAuthentication diz à Web API para ignorar qualquer autenticação que oace antes do pedido chegar ao pipeline Web API, seja por IIS ou por middleware OWIN. Dessa forma, podemos restringir a API web a autenticar apenas usando fichas portadoras.