В контексте рамок безопасности несколько терминов обычно встречаются субъект, пользователь и главный, из которых я не смог найти четкое определение и разницу между ними.
Итак, что именно означают эти термины и почему нужны эти различия субъекта и main?
Они иерархичны в том смысле, что род, вид и индивид являются иерархическими.
Объект/объект наследуется от тех же терминов, что и в грамматике. В предложении субъект - это актер, и объект - это вещь, на которой действовали. В этом смысле использование уже существует до того, как были изобретены компьютеры. В контексте безопасности субъект - это все, что может сделать запрос. Как отмечалось выше, это не должно ограничиваться защитой ИТ и, следовательно, является очень широкой классификацией. Интересно то, что субъект подразумевает объект. Без объекта нет предмета.
Принципы - это то, что разрешено субъектам. Когда вы представляете свою кредитную карту, вы являетесь субъектом, а номер счета является основным. В других контекстах ваш пользовательский идентификатор или идентификатор, выданный государством, является вашим директором. Но принципы могут быть связаны со многими типами предметов, которые не являются людьми. Когда приложения запрашивают функции системного уровня, руководитель может подписаться на подписанный исполняемый модуль кода, но даже в этом случае пользователь, управляющий запросом, все еще остается объектом.
Пользователь более конкретно, чем субъект или руководитель, поскольку он обычно относится к интерактивному оператору. Вот почему у нас есть графический интерфейс пользователя, а не графический интерфейс. Пользователь представляет собой экземпляр объекта, который разрешает директору. Один пользователь может разрешить любое количество участников, но ожидается, что какой-либо директор разрешит одному пользователю (при условии, что люди соблюдают требование об обмене идентификаторами). В приведенном выше примере подписант исполняемого модуля кода определенно не является пользователем, но является действительным директором. Интерактивным оператором, пытающимся загрузить модуль, является пользователь.
Как отмечалось в комментариях, даже авторитетные источники не согласны с этими условиями. Я искал NIST, SANS, IEEE, MITER и несколько "квазиавторитетных" источников, таких как руководства по проверке безопасности при подготовке этого ответа. Ни один источник, который я нашел, который был, по крайней мере, квази-авторитетным, охватывал все три термина, и все они значительно отличались в их использовании. Это мое мнение о том, как использовать термины, но с практической точки зрения, когда вы просматриваете руководство в середине ночи, определения, как правило, принадлежат к тому, что говорят продавцы или писатели. Надеюсь, хотя ответы здесь обеспечат достаточную проницательность для навигации по водам и проанализируют любой документ безопасности, используя эти условия.
Посмотрите на мою концептуальную карту аутентификации:
Я думаю, что терминология взята из JAAS.
Когда приложение использует JAAS аутентификации для аутентификации пользователя (или другого объекта, такого как службы), Тема создается как результат. Целью Субъекта является для представления аутентифицированного пользователя. Предмет состоит из набора Принципы, где каждый директор представляет собой идентификатор для этого пользователя. Например, субъект может иметь имя Principal ( "Сьюзан Смит" ) и Номер социального страхования ( "987-65-4321" ), тем самым отличая этот предмет от других Испытуемые.
Тема - это объект, который запрашивает службу. Это может быть пользователь или процесс. Вероятно, именно поэтому вместо темы было выбрано имя Subject.
Когда субъект пытается получить доступ к службе, субъект должен быть аутентифицирован первым. Успешная аутентификация заканчивается загрузкой Принципов безопасности для этого объекта. Например, в системе контроля доступа на основе ролей аутентифицированный (зарегистрированный) пользователь обычно имеет два принципала - userId и roleId. В таких системах привилегии (то есть кто может получить доступ к каким) указаны как для ролей, так и для пользователей. Во время авторизации (т.е. Проверяя, разрешена ли запрашиваемая услуга), система безопасности будет проверять наличие доступности для обоих участников.
Следовательно, с точки зрения авторизации руководители - это фактические объекты, для которых доступ разрешен или запрещен. Тема - это просто пользователь/поток/процесс, в котором содержатся некоторые принципы.
Как пояснил T.Rob, Subject - это любой объект, который запрашивает доступ к объекту. Начиная с этого момента я нашел комментарий к javax.security.auth.Subject, который я нашел ОЧЕНЬ полезным и понятным:
"Субъекты могут потенциально иметь множественные идентификаторы. Каждая личность представляется в качестве Принципала в Субъекте. Принципалы просто связывают имена с Субъектом. Например, Субъект, который является лицом, Алиса, может иметь двух Принципов: один который связывает" Alice Bar ", имя в ее водительской лицензии, с Субъектом, а другой, который связывает" 999-99-9999", номер на ее идентификационной карточке студента с Субъектом. Оба директора ссылаются на тот же предмет даже если у каждого есть другое имя.
Надеюсь, что это поможет.
Это ссылка ниже для объяснения из документации Oracle JAVA SE.
Субъекты, принципы, аутентификация и учетные данные Чтобы разрешить доступ к ресурсам, приложения сначала должны аутентифицировать источник запроса. Структура JAAS определяет термин субъект для представления источника запроса. Субъектом может быть любое лицо, например лицо или услуга. Субъект представлен класс javax.security.auth.Subject.
Аутентификация представляет собой процесс, посредством которого идентификация субъекта проверяется и должна выполняться безопасным образом; в противном случае исполнитель может выдавать себя за других, чтобы получить доступ к системе. Аутентификация обычно включает субъект, демонстрирующий некоторые доказательства, подтверждающие его личность. Такими доказательствами могут быть только те сведения, которые, вероятно, знают или имеют (например, пароль или отпечаток пальца), или это может быть информация, которую может произвести только субъект (например, подписанные данные с использованием закрытого ключа).
После аутентификации объект заполняется связанными идентификаторами или Принципы (типа java.security.Principal). У субъекта может быть много Принципов. Например, у человека может быть имя Principal ( "John Doe" ) и Принцип SSN ( "123-45-6789" ), которые отличают его от других Субъектов.
В дополнение к связанным Принципалам субъект может иметь атрибуты, связанные с безопасностью, которые называются учетными данными. Учетные данные могут содержать информацию, используемую для аутентификации субъекта для новых услуг. Такие учетные данные включают пароли, билеты Kerberos и сертификаты открытых ключей. Учетные данные также могут содержать данные, которые позволяют субъекту выполнять определенные действия. Например, криптографические ключи представляют учетные данные, которые позволяют субъекту подписывать или шифровать данные. Публичные и частные классы учетных данных не являются частью основного J2SE API. Поэтому любой класс может представлять учетные данные.