Solución:
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 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, el 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 hay un protocolo dedicado para hacerlo: OpenID-Connect.
La razón para tener su propio Servicio de token de seguridad (STS) sería salvaguardar sus activos de información, a través de la 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 de 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ía 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 se trate de 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 API, 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 la Configure método en Startup.cs coloque 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)
{
// check user's password hash in database
// retrieve user info
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.
TL; DR
Realmente me gustaría mostrar una publicación completa sobre cómo implementar correctamente IdentityServer4, pero intenté encajar todo el texto, pero estaba más allá del límite de lo que StackOverflow acepta, así que en su lugar corregiré algunos consejos y cosas que he aprendido.
¿Cuáles son los beneficios de utilizar una identidad de servidor de tokens frente a ASP?
Un servidor de tokens tiene muchos beneficios, pero no es adecuado para todos. Si está implementando una solución empresarial, donde desea que varios clientes puedan iniciar sesión, el servidor Token es su mejor opción, pero si solo está creando un sitio web simple que desea admitir inicios de sesión externos, puede salir adelante con ASP Identity y algo de Middleware.
Consejos de Identity Server 4
El servidor de identidad 4 está bastante bien documentado en comparación con muchos otros marcos que he visto, pero es difícil comenzar desde cero y ver la imagen completa.
Mi primer error fue intentar usar OAuth como autenticación, sí, hay formas de hacerlo, pero OAuth es para autorización, no autenticación, si desea autenticarse, use OpenIdConnect (OIDC)
En mi caso, quería crear un cliente javascript, que se conecta a una api web. Miré muchas de las soluciones, pero inicialmente traté de usar webapi para llamar a Authenticate contra Identity Server y solo iba a hacer que ese token persistiera porque se verificó contra el servidor. Ese flujo puede funcionar potencialmente, pero tiene muchos defectos.
Finalmente, el flujo adecuado cuando encontré la muestra del cliente Javascript obtuve el flujo correcto. Su Cliente inicia sesión y establece un token. Luego, su api web consume el cliente OIdc, que verificará su token de acceso contra IdentityServer.
Conexión a tiendas y migraciones
Al principio, tenía muchos conceptos erróneos sobre las migraciones. Tenía la impresión de que ejecutar una migración generaba el SQL desde el dll internamente, en lugar de usar el contexto configurado para descubrir cómo crear el SQL.
Existen dos sintaxis para las migraciones, saber cuál usa su computadora es importante:
dotnet ef migrations add InitialIdentityServerMigration -c ApplicationDbContext
Add-Migration InitialIdentityServerDbMigration -c ApplicationDbContext
Creo que el parámetro después de la migración es el nombre, no estoy seguro de por qué necesita un nombre, el ApplicationDbContext es un DbContext Code-First en el que desea crear.
Las migraciones usan algo de magia automática para encontrar su cadena de conexión de cómo está configurada su inicio, simplemente asumí que usaba una conexión desde el Explorador de servidores.
Si tiene varios proyectos, asegúrese de tener el proyecto con ApplicationDbContext configurado como inicio.
Hay muchas partes móviles cuando se implementa la autorización y la autenticación. Con suerte, esta publicación ayuda a alguien. La forma más fácil de comprender completamente las autenticaciones es separar sus ejemplos para unir todo y asegurarse de leer la documentación.
Identidad ASP.NET: esta es la compilación para autenticar su aplicación, ya sea portador o autenticación básica, nos brinda el código listo para realizar el registro de usuario, inicio de sesión, cambio de contraseña y todo.
Ahora considere que tenemos 10 aplicaciones diferentes y no es factible hacer lo mismo en las 10 aplicaciones. esa muy frágil y muy mala práctica.
Para resolver este problema, lo que podemos hacer es centralizar nuestra Autenticación y autorización para que cada cambio con esto no afecte a todas nuestras 10 aplicaciones.
El servidor de identidad le ofrece la posibilidad de hacer lo mismo. Podemos crear una aplicación web de muestra que se acaba de utilizar como servicio de identidad y validará a su usuario y le proporcionará un token de acceso JWT.