TL; DR
IdentityServer = servicios de validación y cifrado de tokens a través de OAuth 2.0 / OpenId-Connect
ASP.NET Identity = estrategia actual de gestión de identidades en ASP.NET
¿Cómo puedo autenticarme de manera similar a la forma en que se realizaba en versiones anteriores de .Net si la forma anterior todavía funciona o hay una versión más nueva?
No veo ninguna razón por la que no pueda lograr la forma anterior en ASP.NET Core, pero en general, esa estrategia fue reemplazada por ASP.NET Identity, y ASP.NET Identity está viva y bien en ASP.NET Core.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity
ASP.NET Identity utiliza un almacén de respaldo como SQL Server para almacenar información del usuario como nombre de usuario, contraseña (hash), correo electrónico, teléfono y se puede extender fácilmente para contener Nombre, Apellido o cualquier otra cosa. Entonces, realmente no hay razón para encriptar la información del usuario en una cookie y pasarla de un cliente a otro. Admite nociones como reclamos de usuario, tokens de usuario, roles de usuario e inicios de sesión externos. Aquí están las entidades en ASP.NET Identity:
- AspNetUsers
- AspNetUserRoles
- AspNetUserClaims
- AspNetUserLogins (para vincular proveedores de identidad externos, como Google, AAD)
- AspNetUserTokens (para almacenar cosas como access_tokens y refresh_tokens acumulados por el usuario)
¿Cuáles son los pros y los contras de usar sus propios versículos de servidor de tokens para crear su propio principio personalizado?
Un servidor de tokens sería un sistema que genera una estructura de datos simple que contiene información de autorización y / o autenticación. La autorización generalmente toma el nombre de un token llamado access_token . Estas serían las "llaves de la casa", por así decirlo, que le permitirán atravesar la puerta y entrar en la residencia de un recurso protegido, generalmente una API web. Para la autenticación, id_token
contiene un identificador único para un usuario / persona. Si bien es común poner un identificador de este tipo en el access_token, ahora existe un protocolo dedicado para hacerlo: OpenID-Connect .
La razón para tener su propio Security Token Service (STS) sería proteger sus activos de información, a través de criptografía, y controlar qué clientes (aplicaciones) pueden acceder a esos recursos. Además, los estándares para los controles de identidad ahora existen en las especificaciones OpenID-Connect. IdentityServer es un ejemplo de un servidor de autorización OAuth 2.0 combinado con un servidor de autenticación OpenID-Connect.
Pero nada de esto es necesario si solo desea una tabla de usuario en su aplicación. No necesita un servidor de tokens, solo use ASP.NET Identity. ASP.NET Identity asigna su usuario a un objeto ClaimsIdentity en el servidor, sin necesidad de una clase IPrincipal personalizada.
Cuando use una solución basada en la nube o un servidor Token separado, ¿cómo lo integraría con su aplicación actual? ¿Todavía necesitaría una tabla de usuarios en mi aplicación? ¿Cómo asociaría los dos?
Consulte estos tutoriales para integrar soluciones de identidad independientes con una aplicación:
https://identityserver4.readthedocs.io/en/latest/quickstarts/0_overview.html
https://auth0.com/docs/quickstart/webapp/aspnet-core
Como mínimo, necesitará una tabla de dos columnas que asigne el nombre de usuario al identificador de usuario del proveedor externo. Esto es lo que hace la tabla AspNetUserLogins en ASP.NET Identity. Sin embargo, las filas de esa tabla dependen de que sea un registro de usuario en AspNetUsers.
ASP.NET Identity admite proveedores externos como Google, Microsoft, Facebook, cualquier proveedor de OpenID-Connect, Azure AD ya están allí. (Google y Microsoft ya han implementado el protocolo OpenID-Connect, por lo que tampoco necesita sus paquetes de integración personalizados, como este , por ejemplo). Además, ADFS aún no está disponible en ASP.NET Core Identity.
Consulte este documento para comenzar con proveedores externos en ASP.NET Identity:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/
Dado que hay tantas soluciones diferentes, ¿cómo puedo crear una aplicación empresarial para permitir el inicio de sesión a través de Gmail / Facebook y al mismo tiempo poder expandirme a otros SSO?
Como se explicó anteriormente, ASP.NET Identity ya hace esto. Es bastante fácil crear una tabla de "Proveedores externos" y los datos controlan su proceso de inicio de sesión externo. Entonces, cuando aparece un nuevo "SSO", simplemente agregue una nueva fila con las propiedades como la URL del proveedor, la identificación del cliente y el secreto que le brindan. ASP.NET Identity ya tiene la interfaz de usuario integrada en las plantillas de Visual Studio, pero consulte Inicio de sesión social para conocer los botones más interesantes.
Resumen
Si solo necesita una tabla de usuarios con capacidades de inicio de sesión con contraseña y un perfil de usuario, entonces ASP.NET Identity es perfecto. No es necesario involucrar a autoridades externas. Pero, si tiene muchas aplicaciones que necesitan acceder a muchas apis, entonces una autoridad independiente para asegurar y validar tokens de identidad y acceso tiene sentido. IdentityServer es una buena opción , o vea openiddict-core o Auth0 para una solución en la nube.
Mis disculpas es que esto no está dando en el blanco o si es demasiado introductorio. No dude en interactuar para llegar a la diana que está buscando.
Anexo: autenticación de cookies
Para realizar una autenticación básica con cookies, siga estos pasos. Pero, que yo sepa, no se admite una entidad de seguridad personalizada. Para lograr el mismo efecto, utilice la lista de Reclamaciones del ClaimPrincipal
objeto.
Cree una nueva aplicación web ASP.NET Core 1.1 en Visual Studio 2015/2017 eligiendo "Sin autenticación" en el cuadro de diálogo. Luego agregue el paquete:
Microsoft.AspNetCore.Authentication.Cookies
Bajo el Configure
método Startup.cs
implementado esto (antes app.UseMvc
):
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationScheme = "MyCookieMiddlewareInstance",
LoginPath = new PathString("/Controller/Login/"),
AutomaticAuthenticate = true,
AutomaticChallenge = true
});
Luego, cree una interfaz de usuario de inicio de sesión y publique el formulario html en un método de acción 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();
}
El objeto HttpContext.User debe tener sus reclamos personalizados y se puede recuperar fácilmente la colección List de ClaimPrincipal.
Espero que esto sea suficiente, ya que una Solución / Proyecto completo parece demasiado para una publicación de StackOverflow.