TL; DR
IdentityServer = criptografia de token e serviços de validação via OAuth 2.0 / OpenId-Connect
Identidade ASP.NET = estratégia de gerenciamento de identidade atual em ASP.NET
Como posso autenticar da mesma forma que fazia nas versões anteriores do .Net? O modo antigo ainda funciona ou existe uma versão mais recente.
Não vejo razão para você não conseguir fazer o método antigo no ASP.NET Core, mas, em geral, essa estratégia foi substituída pela Identidade ASP.NET, e a Identidade ASP.NET está viva e bem no ASP.NET Core.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity
A identidade ASP.NET usa um armazenamento de apoio como o SQL Server para armazenar informações do usuário, como nome de usuário, senha (hash), e-mail, telefone e pode ser facilmente estendido para armazenar o nome, o sobrenome ou qualquer outra coisa. Portanto, não há realmente nenhuma razão para criptografar as informações do usuário em um cookie e passá-las de um cliente para o outro. Ele oferece suporte a noções como declarações de usuário, tokens de usuário, funções de usuário e logins externos. Aqui estão as entidades na identidade ASP.NET:
- AspNetUsers
- AspNetUserRoles
- AspNetUserClaims
- AspNetUserLogins (para vincular provedores de identidade externos, como Google, AAD)
- AspNetUserTokens (para armazenar coisas como access_tokens e refresh_tokens acumulados pelo usuário)
Quais são os prós e os contras de usar seus próprios versos de servidor de token criando seu próprio princípio personalizado?
Um servidor de token seria um sistema que gera uma estrutura de dados simples contendo informações de autorização e / ou autenticação. A autorização geralmente leva o for de um token denominado access_token . Essas seriam as "chaves da casa", por assim dizer, permitindo que você passasse pela porta e entre na residência de um recurso protegido, geralmente uma API da web. Para autenticação, o id_token
contém um identificador exclusivo para um usuário / pessoa. Embora seja comum colocar esse identificador no access_token, agora existe um protocolo dedicado para fazer isso: OpenID-Connect .
A razão para ter seu próprio Security Token Service (STS), seria proteger seus ativos de informação, via criptografia, e controlar quais clientes (aplicativos) podem acessar esses recursos. Além disso, os padrões para controles de identidade agora existem nas especificações OpenID-Connect. IdentityServer é um exemplo de servidor de autorização OAuth 2.0 combinado com um servidor de autenticação OpenID-Connect.
Mas nada disso é necessário se você quiser apenas uma tabela de usuário em seu aplicativo. Você não precisa de um servidor de token - apenas use a identidade ASP.NET. A identidade ASP.NET mapeia seu usuário para um objeto ClaimsIdentity no servidor - sem necessidade de uma classe IPrincipal personalizada.
Ao usar uma solução baseada em nuvem ou um servidor Token separado, como você integraria isso ao seu aplicativo atual, se eu ainda precisaria de uma tabela de usuários em meu aplicativo, como você associaria os dois?
Veja estes tutoriais para integrar soluções de identidade separadas com um aplicativo:
https://identityserver4.readthedocs.io/en/latest/quickstarts/0_overview.html
https://auth0.com/docs/quickstart/webapp/aspnet-core
No mínimo, você precisaria de uma tabela de duas colunas mapeando o nome de usuário para o identificador de usuário do provedor externo. Isso é o que a tabela AspNetUserLogins faz na identidade do ASP.NET. As linhas dessa tabela, entretanto, dependem de ser um registro do usuário em AspNetUsers.
ASP.NET Identity oferece suporte a provedores externos como Google, Microsoft, Facebook, qualquer provedor OpenID-Connect, Azure AD já estão lá. (Google e Microsoft já implementaram o protocolo OpenID-Connect para que você também não precise de seus pacotes de integração personalizados, como este , por exemplo). Além disso, o ADFS ainda não está disponível no ASP.NET Core Identity.
Consulte este documento para começar a trabalhar com provedores externos na identidade ASP.NET:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/
Sendo que existem tantas soluções diferentes, como posso criar um aplicativo empresarial, para permitir Login através do Gmail / Facebook enquanto ainda posso expandir para outros SSO's
Conforme explicado acima, a identidade do ASP.NET já faz isso. É bastante fácil criar uma tabela de "Provedores externos" e os dados direcionam seu processo de login externo. Portanto, quando um novo "SSO" surgir, basta adicionar uma nova linha com as propriedades como o url do provedor, o ID do cliente e o segredo que eles fornecem. A identidade do ASP.NET já tem a IU incorporada aos modelos do Visual Studio, mas consulte Login social para botões mais frios.
Resumo
Se você só precisa de uma tabela de usuários com recursos de entrada de senha e um perfil de usuário, a identidade ASP.NET é perfeita. Não há necessidade de envolver autoridades externas. Mas, se houver muitos aplicativos que precisam acessar muitas apis, uma autoridade independente para proteger e validar a identidade e os tokens de acesso faz sentido. IdentityServer é um bom ajuste, ou veja openiddict-core ou Auth0 para uma solução em nuvem.
Minhas desculpas é que isso não atingiu o alvo ou é muito introdutório. Sinta-se à vontade para interagir para obter o centro do alvo que você está procurando.
Adendo: autenticação de cookie
Para fazer autenticação básica com cookies, siga estas etapas. Mas, que eu saiba, um principal de declarações customizado não é compatível. Para obter o mesmo efeito, utilize a lista de reivindicações do ClaimPrincipal
objeto.
Crie um novo aplicativo da Web ASP.NET Core 1.1 no Visual Studio 2015/2017 escolhendo "Sem autenticação" na caixa de diálogo. Em seguida, adicione o pacote:
Microsoft.AspNetCore.Authentication.Cookies
De acordo com o Configure
método em Startup.cs
vigor isto (antes app.UseMvc
):
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationScheme = "MyCookieMiddlewareInstance",
LoginPath = new PathString("/Controller/Login/"),
AutomaticAuthenticate = true,
AutomaticChallenge = true
});
Em seguida, crie uma interface de usuário de login e poste o formulário html em um método de ação como este:
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Login(String username, String password, String returnUrl = null)
{
ViewData["ReturnUrl"] = returnUrl;
if (ModelState.IsValid)
{
var claims = new List<Claim>
{
new Claim(ClaimTypes.Name, username),
new Claim("FirstName", "Alice"),
new Claim("LastName", "Smith")
};
var identity = new ClaimsIdentity(claims, "Password");
var principal = new ClaimsPrincipal(identity);
await HttpContext.Authentication.SignInAsync("MyCookieMiddlewareInstance", principal);
return RedirectToLocal(returnUrl);
}
ModelState.AddModelError(String.Empty, "Invalid login attempt.");
return View();
}
O objeto HttpContext.User deve ter suas declarações personalizadas e podem ser facilmente recuperadas pela coleção List de ClaimPrincipal.
Espero que isso seja suficiente, pois uma solução / projeto completo parece um pouco demais para um post StackOverflow.