c# - español - asp.net core identity

.NET Core Identity Server 4 Autenticación VS Autenticación de identidad

Question

Estoy tratando de entender la forma correcta de hacer la autenticación en ASP.NET Core. He visto varios recursos (la mayoría de los cuales están desactualizados).

• Simple-Implementation-Of-Microsoft-Identity

• Introducción a la autenticación con ASP.Core

• Introducción a la identidad de MSDN

Algunas personas ofrecen soluciones alternativas que indican el uso de una solución basada en la nube, como Azure AD, o el uso de IdentityServer4 y alojar mi propio servidor de token.

En la versión anterior de .Net, una de las formas más simples de autenticación sería crear un Principio personalizado y almacenar en su interior datos de usuario de autenticación adicionales.

public interface ICustomPrincipal : System.Security.Principal.IPrincipal
{
    string FirstName { get; set; }

    string LastName { get; set; }
}

public class CustomPrincipal : ICustomPrincipal
{
    public IIdentity Identity { get; private set; }

    public CustomPrincipal(string username)
    {
        this.Identity = new GenericIdentity(username);
    }

    public bool IsInRole(string role)
    {
        return Identity != null && Identity.IsAuthenticated && 
           !string.IsNullOrWhiteSpace(role) && Roles.IsUserInRole(Identity.Name, role);
    }

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public string FullName { get { return FirstName + " " + LastName; } }
}

public class CustomPrincipalSerializedModel
{
    public int Id { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }
}

Luego, serializaría sus datos en una cookie y los devolvería al cliente.

public void CreateAuthenticationTicket(string username) {     

    var authUser = Repository.Find(u => u.Username == username);  
    CustomPrincipalSerializedModel serializeModel = new CustomPrincipalSerializedModel();

    serializeModel.FirstName = authUser.FirstName;
    serializeModel.LastName = authUser.LastName;
    JavaScriptSerializer serializer = new JavaScriptSerializer();
    string userData = serializer.Serialize(serializeModel);

    FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
    1,username,DateTime.Now,DateTime.Now.AddHours(8),false,userData);
    string encTicket = FormsAuthentication.Encrypt(authTicket);
    HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
    Response.Cookies.Add(faCookie);
}

Mis preguntas son:

1. ¿Cómo puedo autenticarme de manera similar a como se hizo en versiones anteriores de .Net? La manera antigua todavía funciona o hay una versión más nueva.

2. ¿Cuáles son las ventajas y desventajas de usar sus propios versos de servidor de tokens para crear su propio principio personalizado?

3. Cuando use una solución basada en la nube o un servidor Token separado, ¿cómo integraría eso con su aplicación actual? ¿Todavía necesitaría una tabla de usuarios en mi aplicación? ¿Cómo asociaría los dos?

4. 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?

5. ¿Cuáles son algunas implementaciones simples de estas tecnologías?

Answer 1

Identidad ASP.NET: esta es la compilación de una manera de autenticar su aplicación, ya sea portadora o autenticación básica, nos da el código listo para realizar el registro del usuario, iniciar sesión, cambiar la 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 cualquier cambio con esto no afecte a nuestras 10 aplicaciones.

El servidor de identidad le brinda la capacidad de hacer lo mismo. podemos crear una aplicación web de muestra que se acaba de usar como servicio de identidad y validará a su usuario y le proporcionará algunos tokens de acceso JWT.

Answer 2

Los inicios de sesión sociales no son difíciles de implementar con Identity, pero hay una configuración inicial involucrada y, a veces, los pasos que encuentra en línea en los documentos no son idénticos, por lo general, puede encontrar ayuda para eso en la sección de desarrolladores de la plataforma que está tratando de configurar los inicios de sesión sociales para. La identidad es el reemplazo de la antigua funcionalidad de membresía que se encuentra en las versiones heredadas de .NET Framework. Lo que he encontrado sorprendente es que los casos de uso de borde, como pasar un token jwt que ya tienes a una API web, no están cubiertos en ningún lugar en los ejemplos en línea incluso en plural, estoy seguro de que no necesita su propia autoridad de token para hacer esto, pero no he encontrado un solo ejemplo sobre cómo pasar datos en un get o post que no se trata de un servidor autohospedado.

Answer 3

Siempre he usado la autorización / autenticación de identidad ASP.NET incorporada (y anteriormente membresía), he implementado Auth0 recientemente ( Auth0 ) y recomiendo esto como algo más para probar.

Answer 4

TL; DR

IdentityServer = servicios de encriptación y validación de token a través de OAuth 2.0 / OpenId-Connect

ASP.NET Identity = estrategia de gestión de identidad actual en ASP.NET

¿Cómo puedo autenticarme de manera similar a como se hizo en versiones anteriores de .Net? La manera antigua todavía funciona o hay una versión más nueva.

No veo ninguna razón por la que no pueda lograr la antigua manera 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. Por lo tanto, realmente no hay razón para cifrar la información del usuario en una cookie y pasarla de un cliente a otro. Admite nociones como notificaciones de usuarios, tokens de usuario, roles de usuario e inicios de sesión externos. Estas son 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 acumuladas por el usuario)

¿Cuáles son las ventajas y desventajas de usar sus propios versos 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 la forma de un token llamado access_token . Estas serían las "llaves de la casa", por así decirlo, permitiéndole atravesar la puerta y entrar a 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 dicho identificador en 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 proteger sus activos de información, mediante 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 integraría eso 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 separadas 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 sea un registro de Usuario en AspNetUsers.

ASP.NET Identity es compatible con 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 a utilizar proveedores externos en Identidad ASP.NET:

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, la identidad ASP.NET ya hace esto. Es bastante fácil crear una tabla de "Proveedores externos" y los datos impulsan su proceso de inicio de sesión externo. Entonces, cuando aparezca 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 proporcionan. ASP.NET Identity ya tiene la interfaz de usuario integrada en las plantillas de Visual Studio, pero vea Social Login para botones más geniales.

Resumen

Si solo necesita una tabla de usuarios con capacidades de inicio de sesión con contraseña y un perfil de usuario, la identidad ASP.NET es perfecta. No es necesario involucrar a autoridades externas. Pero, si tiene muchas aplicaciones que necesitan acceder a muchas API, entonces tiene sentido una autoridad independiente para asegurar y validar tokens de identidad y acceso. IdentityServer es una buena openiddict-core , 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. Por favor, siéntase libre de 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 un director de reclamos personalizados. Para lograr el mismo efecto, utilice la lista de ClaimPrincipal objeto ClaimPrincipal .

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 método Configure en Startup.cs coloque esto (antes de 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 puede recuperarse fácilmente la colección List del ClaimPrincipal.

Espero que esto sea suficiente, ya que una solución / proyecto completo parece un poco demasiado para una publicación de .

Answer 5

TL; DR

Realmente me gustaría mostrar una publicación completa sobre cómo implementar correctamente IdentityServer4, pero traté de incluir todo el texto, pero estaba más allá del límite de lo que acepta , así que en su lugar corregiré algunos consejos y cosas que he aprendido.

¿Cuáles son los beneficios de usar una identidad ASP de servidor de token vs ASP?

Un servidor de tokens tiene muchos beneficios, pero no es adecuado para todos. Si está implementando una solución similar a la empresa, donde desea que varios clientes puedan iniciar sesión, el servidor Token es su mejor opción, pero si solo está haciendo un sitio web simple que desee admitir inicios de sesión externos, puede salirse con la identidad ASP y un poco de middleware

Identity Server 4 Tips

Identity Server 4 está bastante bien documentado en comparación con muchos otros frameworks que he visto, pero es difícil comenzar desde cero y ver la imagen completa.

Mi primer error fue tratar de usar OAuth como autenticación. Sí, hay formas de hacerlo, pero OAuth es para Autorización, no para autenticación, si desea Autenticar use OpenIdConnect (OIDC)

En mi caso, quería crear un cliente JavaScript A, que se conecta a una API web. Miré muchas de las soluciones, pero inicialmente intenté usar el webapi para llamar a Authenticate contra Identity Server y solo iba a tener ese token persistente porque se verificó en el servidor. Ese flujo potencialmente puede funcionar, pero tiene muchos defectos.

Finalmente, el flujo correcto cuando encontré la muestra del Cliente Javascript obtuve el flujo correcto. Tu cliente inicia sesión y establece un token. Luego, hace que su API web consuma el Cliente OIdc, que verificará que sea un token de acceso contra IdentityServer.

Conexión a tiendas y migraciones Al principio tuve muchas ideas erróneas sobre migraciones. Tenía la impresión de que ejecutar una migración generó el SQL desde el dll internamente, en lugar de usar su contexto configurado para descubrir cómo crear el SQL.

Hay dos sintaxis para las migraciones, sabiendo 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, por qué necesita un nombre, no estoy seguro, el ApplicationDbContext es un Code-First DbContext 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 puesta en marcha, simplemente asumí que usaba una conexión desde el Explorador de servidores.

Si tiene varios proyectos, asegúrese de tener el proyecto con el ApplicationDbContext establecido como inicio.

Hay muchas partes móviles al implementar la autorización y la autenticación. Esperemos que esta publicación ayude a alguien. La forma más fácil de comprender completamente las autenticaciones es separar sus ejemplos para unir todo y asegurarse de que lea la documentación