Нужен ли наш Identity Server, если нам не нужны SSO или OAuth 2? - PullRequest
0 голосов
/ 19 апреля 2019

Наша инфраструктура выглядит следующим образом:

  • Сервер аутентификации IdentityServer4,
  • .NET Core 2.2 web api
  • Угловой SPA1
  • Угловой SPA2
  • MVC MVCApp1

Насколько я понимаю, целью Identity Server 4 является выполнение одной из 2 вещей:

  1. Единая регистрация,Таким образом, вы входите в SPA1, вы все еще входите в SPA2 и MVCApp1.

  2. Авторизуйте пользователей в сторонних приложениях для входа через поток OAuth 2.0 и предоставьте наши данные стороннимapp.

Для # 1 никто не должен каждый оставаться в системе, потому что все SPA1 и SPA2 и MVCApp1 в основном имеют разных конечных пользователей.Ака нам не нужен SSO.Для # 2 не имеет значения, потому что мы никогда не допустим этого.

Это означает, что у нас есть проект IdentityServer 4, который выглядит как излишний, и его очень сложно отладить.Такие вещи, как пользователи, делающие закладки на сервере аутентификации вместо приложения, перенаправляют при случайном сбое и т. Д.

Мой вопрос: можно ли вместо этого просто переключиться на аутентификацию пользователя в API и убить этот Identity Server?Мы можем легко добавить конечную точку аутентификации в API.Есть ли что-нибудь менее безопасное в этом?

Примерно так:

    [AllowAnonymous]
    [HttpPost("authenticate")]
    public IActionResult Authenticate([FromBody]UserDto userDto)
    {
        var user = _userService.Authenticate(userDto.Username, userDto.Password);

        if (user == null)
            return Unauthorized();

        var tokenHandler = new JwtSecurityTokenHandler();
        var key = Encoding.ASCII.GetBytes(_appSettings.Secret);
        var tokenDescriptor = new SecurityTokenDescriptor
        {
            Subject = new ClaimsIdentity(new Claim[] 
            {
                new Claim(ClaimTypes.Name, user.Id.ToString())
            }),
            Expires = DateTime.UtcNow.AddDays(7),
            SigningCredentials = new SigningCredentials(new SymmetricSecurityKey(key), SecurityAlgorithms.HmacSha256Signature)
        };
        var token = tokenHandler.CreateToken(tokenDescriptor);
        var tokenString = tokenHandler.WriteToken(token);

        // return basic user info (without password) and token to store client side
        return Ok(new {
            Id = user.Id,
            Username = user.Username,
            FirstName = user.FirstName,
            LastName = user.LastName,
            Token = tokenString
        });
    }

1 Ответ

2 голосов
/ 19 апреля 2019

Я не могу ответить на ваш вопрос, нужно ли это, поскольку это может быть основано на мнении.Но у меня есть несколько замечаний.

IdentityServer - это реализация OpenID Connect поверх OAuth2.Если вы не хотите использовать OpenID Connect и OAuth2, то IdentityServer может оказаться неподходящим инструментом.

Однако IdentityServer делает больше, чем просто реализует спецификации.Это также разделение обязанностей.

С центральным органом управления приложениям не нужно реализовывать функции входа в систему.В самом простом потоке пользователь входит в систему IdentityServer, предоставляя пользователю токен, и с этим токеном клиент может получить доступ к ресурсу от имени пользователя.Все, что нужно сделать ресурсу, - это проверить полномочия.

Единственная ответственность - это хороший дизайн, отделяющий логику входа в систему от бизнес-логики (разделение проблем) и создающую более безопасную среду.SSO - это просто «побочный эффект», который можно отключить.Ресурс и клиент не должны иметь доступа к таблицам идентификации.

Но речь идет также о защите ваших ресурсов.С IdentityServer довольно легко настроить, какой клиент имеет доступ к какому ресурсу, используя наиболее подходящий поток.

IdentityServer заботится об аутентификации и базовой авторизации.Где аутентификация является ответственностью IdentityServer.В результате все пользователи имеют доступ к каждому клиенту / ресурсу.Авторизация на самом деле является заботой ресурса.Вот почему они придумали PolicyServer .

С авторизацией Asp.Net Core у вас будет много вариантов реализации авторизации.

Я не могу сказать вам, что делать, и я уверен, что все возможно.Но если взглянуть на принципы проектирования, я бы предпочел разделить проблемы.

О вашем коде, семидневное окно доступа довольно велико.Особенно, если вы не можете отозвать токен.

О пользователях, ссылающихся на неправильную страницу, хорошо, вы не можете предотвратить все.

...