Авторизация через управление доступом

Авторизация — это процесс предоставления пользователям доступа к различным частям и ресурсам веб-приложения. Распространённый способ авторизации пользователей — управление доступом, при котором администратор сайта определяет, какие разрешения должны быть предоставлены пользователям и другим сущностям для доступа к тем или иным ресурсам.

Авторизацию не следует путать с аутентификацией — процессом проверки того, что пользователь является тем, кем представляется, обычно осуществляемым путём предоставления учётных данных. После того как пользователь прошёл аутентификацию, процесс авторизации всё равно должен выполняться при каждом запросе, чтобы убедиться, что пользователь имеет доступ к запрошенному ресурсу.

При обращении к приложению через GraphQL необходимо проверять, имеет ли пользователь доступ к запрошенным элементам схемы. Должна ли логика авторизации быть реализована внутри слоя GraphQL?

Ответ: нет. Как явно указывает документация на graphql.org, логика авторизации относится к слою бизнес-логики, откуда к ней обращается GraphQL. Таким образом, приложение может иметь единственный источник истины для авторизации (то есть тот, который предоставляет WordPress):

Gato GraphQL соблюдает этот принцип, отражая (и, на уровне движка, делегируя) механизм авторизации, предоставляемый WordPress.

​

Политики управления доступом

Среди нескольких политик управления доступом, которые можно реализовать в приложении, наиболее популярными являются Role-Based Access Control (RBAC) и Attribute-Based Access Control (ABAC).

WordPress и Gato GraphQL поддерживают обе политики.

При использовании Role-Based Access Control разрешения предоставляются на основе ролей, которые затем назначаются пользователям. Например, WordPress имеет роль administrator с доступом ко всем ресурсам, а также роли editor, author, contributor и subscriber с ограниченными разрешениями в различной степени — например, возможность создавать и публиковать запись в блоге, только создавать её или только читать.

При использовании Attribute-Based Access Control разрешения предоставляются на основе метаданных, которые могут назначаться различным сущностям, включая пользователей, ресурсы и условия среды (например, время суток или IP-адрес посетителя). В WordPress, например, возможность edit_others_posts используется для проверки того, может ли пользователь редактировать записи других пользователей.

В общих чертах, ABAC предпочтительнее RBAC, поскольку позволяет настраивать разрешения с детальным контролем, а само разрешение однозначно в своей цели.

Например, в WordPress роль editor обладает возможностью edit_others_posts, однако может возникнуть желание разрешить пользователю с ролью author редактировать записи другого автора, не предоставляя ему весь набор разрешений редактора (например, право удалять записи других авторов). Поэтому предоставление возможности edit_others_posts и проверка этого условия более уместны, чем проверка роли editor.

​

Определение видимости

Если пользователь не имеет разрешения на доступ к запрошенному полю схемы GraphQL, какую ошибку следует возвращать?

Существует два варианта в зависимости от желаемой видимости схемы: публичная или приватная.

Для публичной схемы открытая схема GraphQL одинакова для всех пользователей, и каждое поле описывает, какие разрешения требуются для доступа к нему. При запросе недоступного поля сообщение об ошибке объяснит, почему пользователю отказано в доступе.

Для приватной схемы схема GraphQL настраивается индивидуально для каждого пользователя, и открываются только те поля, к которым пользователь имеет доступ. При запросе недоступного поля сообщение об ошибке будет указывать, что поле не существует.

​

Управление доступом через пользовательский интерфейс

В Gato GraphQL правила управления доступом внедряются в схему во время выполнения как пользовательская конфигурация через access control lists. Таким образом, слой GraphQL немедленно отразит изменения политики управления доступом без необходимости обновлять какой-либо код или перекомпилировать схему:

Администратор сайта настраивает ACL, выбирая:

• Поля для проверки
• Правило проверки из числа:
  • должен ли пользователь быть авторизован?
  • должен ли пользователь быть не авторизован?
  • должен ли пользователь иметь определённую роль?
  • должен ли пользователь иметь определённую возможность?
• Конфигурацию, специфичную для правила:
  • какие роли?
  • какие возможности?
• Видимость:
  • по умолчанию (то есть та же, что назначена схеме)?
  • публичная?
  • приватная?