c# - tables - Usar cuentas de dominio de Windows y cuentas administradas por aplicaciones

mvc 5 identity authentication

Question

Es fácil crear una aplicación MVC de ASP.NET que se autentique según el usuario de dominio de Windows. También es fácil crear una que use cuentas individuales almacenadas utilizando Entity Framework . De hecho, hay plantillas de proyecto para ambos.

Pero quiero utilizar AMBOS tipos de autenticación en la misma aplicación. Intenté combinar el código de ambas plantillas de proyecto. Tengo un problema en Startup.Auth.cs.

// from "Individual Accounts" template
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider
    {
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(30),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
    }
});

La existencia de la autenticación de cookies owin middleware parece hacer que las identidades de dominio no sean autenticadas. Si saco esta línea, la autenticación del dominio funciona. Pero sin él, parece que no puedo admitir cuentas de usuario individuales.

He descargado el código fuente del proyecto katana y he examinado CookieAuthenticationHandler.cs, pero no entiendo bien cómo funciona en el contexto de una canalización OWIN.

¿Cómo puedo usar el marco de identidad de ASP.net para permitir que mi aplicación autentique a los usuarios del dominio de Windows O a un almacén de usuarios específico de la aplicación?

Answer 1

Es por esta razón que no he podido usar soluciones precocidas para la autenticación. En nuestro proyecto, los años pasados ​​(y el enfoque ágil) nos han dejado con 4 formas diferentes de autenticar, lo que es molesto, pero admitimos todas las versiones anteriores de aplicaciones en el campo, por lo que tenemos que preservarlo todo (al menos por ahora).

Terminé creando una fábrica que determina el mecanismo de autenticación (a través de varios medios, como el formato de token, la presencia de alguna otra cosa) y luego devuelve un envoltorio que lleva la lógica para validar ese método de autenticación y establecer el principal.

Esto se inicia en un módulo HTTP personalizado para que el principal se genere y autentifique antes de que la solicitud llegue al controlador. En su caso, Windows Auth sería el último recurso, creo. En nuestra aplicación de API web, adoptamos el mismo enfoque, pero a través de un controlador de delegación en lugar de un módulo HTTP . Es un tipo de federación de token local, se podría decir. La implementación actual nos permite agregar o modificar cualquier procedimiento de validación, o agregar cualquier otro formato de token; al final, el usuario termina con una identidad adecuada o se le niega. Solo tardó unos días en implementarlo.

Answer 2

Me parece que la mejor respuesta a esta pregunta es utilizar un marco de autenticación y autorización. Hay muchos para elegir (tanto comerciales como gratuitos). Usted podría, por supuesto, escribir el suyo propio, pero yo lo desalentaría. Mucha gente muy inteligente se equivoca.

Me gustaría echar un vistazo a IdentityServer3 . Ciertamente no es la única solución, pero es un marco de autenticación y autorización bastante bueno. Es de código abierto y bastante fácil de ponerlo en marcha a toda prisa. Su caso de uso es común y encontrará información muy útil en el enlace anterior. Separación limpia entre autorización y autenticación, opciones de autenticación social, fácil de trabajar con tokens web json que encapsulan las reclamaciones de los usuarios, etc.

Como te puede ayudar

IdentityServer3 le permite configurar los proveedores de identidad para manejar la autenticación y hay muchos puntos de extensión que le permitirán implementar una cadena de responsabilidad que puede manejar ambos escenarios. De la documentación :

IdentityServer admite la autenticación mediante proveedores de identidad externos. El mecanismo de autenticación externa se debe encapsular en un middleware de autenticación Katana.

Katana se entrega con middleware para Google, Facebook, Twitter, cuentas de Microsoft, WS-Federation y OpenID Connect, pero también hay middlewares desarrollados por la comunidad (incluidos Yahoo, LinkedIn y SAML2p).

Para configurar el middleware para los proveedores externos, agregue un método a su proyecto que acepte un IAppBuilder y una cadena como parámetros.

IdentityServer3 admite AD como proveedor de identidad a través de una ventana de inicio de sesión del navegador y admitirá una implementación más programática a través de una concesión personalizada . También puede consultar here más información sobre IdentityServer3 y la autenticación AD.

También será compatible con la autenticación de Windows y puede consultar here para obtener información y ejemplos sobre cómo implementarlo.

También hay un buen ejemplo de cómo empezar.

Con la configuración correcta, IdentityServer3 puede manejar sus requisitos. Necesitará implementar sus propios proveedores de autenticación y conectarlos al marco, pero no hay mucho más que eso. En cuanto a la autorización, hay muchas opciones allí también.

Answer 3

El enfoque más simple es tener 2 Proyectos de presentación diferentes solo para Autenticación / Autorización.

Esto tiene la ventaja de apoyarse en el marco existente y la configuración estándar.

A partir de ahí, usted decide:

• crear un usuario AD para cada usuario de internet, o
• crear un DB / usuario de Internet para cada usuario de AD.

Crear un usuario de Identidad para cada usuario de AD es más fácil de implementar. Entonces, las mismas cookies y filtros pueden existir en toda la aplicación.

En ese caso usted puede:

• usa subdominio (s) para tu aplicación
• AD Authentiction Project puede tener el propósito singular de Autenticación / Autorización, luego la aplicación web puede representar el resto de su aplicación.

Alternativamente, si desea una solución verdaderamente unificada, use MohammadYounes / Owin-MixedAuth

github.com/MohammadYounes/Owin-MixedAuth

Install-Package OWIN-MixedAuth

En web.config

<location path="MixedAuth">
  <system.webServer>
    <security>
      <authentication>
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
</location>

En en Startup.Auth.cs

app.UseMixedAuth(cookieOptions);

:

:

Cómo funciona:

El controlador utiliza ApplyResponseChallengeAsync para confirmar que la solicitud es un desafío 401 . Si es así, se redirige a la ruta de devolución de llamada para solicitar la autenticación de IIS que está configurada para consultar el AD.

        AuthenticationResponseChallenge challenge = Helper.LookupChallenge(
              Options.AuthenticationType, Options.AuthenticationMode);

Un desafío 401 es causado por un usuario no autorizado que intenta usar un recurso que requiere autenticación

El controlador utiliza InvokeAsync para verificar si una solicitud proviene de una ruta de devolución de llamada (IIS) y luego llama a AuthenticateCoreAsync

    protected async override System.Threading.Tasks.Task<AuthenticationTicket>
                AuthenticateCoreAsync()
    {
        AuthenticationProperties properties = UnpackStateParameter(Request.Query);

        if (properties != null)
        {
            var logonUserIdentity = Options.Provider.GetLogonUserIdentity(Context);

            if (logonUserIdentity.AuthenticationType != Options.CookieOptions.AuthenticationType
                && logonUserIdentity.IsAuthenticated)
            {
                AddCookieBackIfExists();

                ClaimsIdentity claimsIdentity = new ClaimsIdentity(
                    logonUserIdentity.Claims, Options.SignInAsAuthenticationType);

                //  ExternalLoginInfo GetExternalLoginInfo(AuthenticateResult result)
                claimsIdentity.AddClaim(new Claim(ClaimTypes.NameIdentifier,
                  logonUserIdentity.User.Value, null, Options.AuthenticationType));

                //could grab email from AD and add it to the claims list.
                var ticket = new AuthenticationTicket(claimsIdentity, properties);

                var context = new MixedAuthAuthenticatedContext(
                   Context,
                   claimsIdentity,
                   properties,
                   Options.AccessTokenFormat.Protect(ticket));

                await Options.Provider.Authenticated(context);

                return ticket;
            }
        }
        return new AuthenticationTicket(null, properties);
    }

AuthenticateCoreAsync utiliza AddCookieBackIfExists para leer la cookie de AddCookieBackIfExists creada por AD y crea sus propias AddCookieBackIfExists en AddCookieBackIfExists .

Los usuarios de AD reciben una cookie basada en notificaciones idéntica a los usuarios de la web. AD es ahora como cualquier otro autenticador de terceros ( Google, FB, LinkedIN )