Получение на стороне сервера имя пользователя

Насколько я понимаю, любая авторизация предполагает идентификацию пользователя, т.е. сопоставление пользователя с некоей учетной записью, предварительно созданной в системе. Поэтому ответ «да».

Я имел ввиду не то что я допустим в своём протоколе на стороне клиента определю имя пользователя и пошлю его серверу. Я имею ввиду чтобы это как то определялось на стороне сервера что называется «по умолчанию» (Из дескриптора сокета). Вот что-то имею ввиду. В случае кербероса да там следует использовать на стороне сервера api kerberos и как то определяется пользователь.

Я имею ввиду чтобы это как то определялось на стороне сервера что называется «по умолчанию» (Из дескриптора сокета)

Если это TCP-сокет, то по нему можно определить IP-адрес и порт другой стороны. Это максимум. О чем-то большем может знать только программа, производившая аутентификацию.

whoami

Это на стороне клиента. Это не подходит сказал же

who?

Да и ps axu выведет кто каким процессов владеет, соотв. можно вычислить кто есть кто. Можно аналогично по доступу к файлам смотреть, кто какой файл захватил. И т.п.

Или пихай в авторизацию доп. скрипт при старте, который сохранит тебе все данные о подключении. Как она у тебя там реализована?

PS: но это имя пользователя под которым он подключился (залогинился) к серверу, как он там у себя на машине клиента называется со стороны сервера не видно.

Это на стороне клиента. Это не подходит сказал же

из сокета ты можешь определить только ендпоинт другого конца. нет там никаких «имен». имя там - ендпоинт - адрес:порт

Во избежание петросянтства и философских обсуждений природы аутентификации и авторизации советую указать, о каком конкретном протоколе идет речь. Например, если клиент логинится в систему через ssh или физический терминал - можно использовать who, как посоветовали выше.

А если логинится, например, в веб-интерфейс, то это уже совсем другая тема.

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

А в общем случае такое можно сделать?

По большому счету, вариантов два:
1. Требовать обязательной аутентификации пользователя - kerberos, ntlm, OpenID Connect, или по встроенной в твое приложение учетной записи пользователя.
2. В корпоративной среде - пытаться угадать пользователя по его ip-адресу. Для этого придётся интегрировать твоё приложение с сервисами, которые знают о связи между пользователями и IP-адресами. Например, в случае AD парсить «Audit logon events», примерно вот в таком ключе - https://manuals.gfi.com/en/exinda/help/content/exos/how-to-guides/activ-dirct... В случае мобильных устройств в корпоративном WiFi, устройства перед попаданием в сеть должны проходить ту или иную аутентификацию, и опять же нужно по логам от этой аутентификации разгадывать, какому пользователю принадлежит мобильное устройство с определенным ip-шником. Систем разных много, это геморрой при разработке, геморрой при внедрении.

Это на стороне клиента. Это не подходит сказал же

Вообще-то это на стороне сервера…

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

А то так, ничего непонятно, чего ты на самом деле хочешь. Слова «в общем случае» это все равно что «можно ли это для абсолютно любых систем и механизмов авторизации», что, разумеется, нельзя.

В случае кербероса

api подключается с двух сторон! и идет согласование билетов. Нельзя доверять любому имени которое пришлет клиент!

Вот бы сливать свой юзернейм каждому TCP-серверу, к которому подключаюсь; всю жизнь мечтал.

А в общем случае такое можно сделать?

1. можно самому раздавать ключи и чужих просто не пущщать

2. можно проверять сертификаты и отклонять самоподписанные

иначе вангую про «локальное имя подлюченного вдаль пользователя» в 70% случаев nobody и wwwdata. (см. IDENT (*))

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

(*) да, когда трава была зеленее и забористей, можно было переспросить IDENT «что за хрен ко мне обращается»..