Лучшие практики в стандартах имен пользователей: как избежать проблем

Это хроническая проблема, когда большие системы управления идентификацией пытаются склеить разнородные системы. Неизменно вы будете ограничены наименьшим общим знаменателем, который слишком часто является 8-символьным буквенно-цифровым ограничением ASCII благодаря какой-то (вероятно устаревшей) Unix-подобной системе где-то в недрах центра обработки данных. Эти модные современные системы могут принимать имена пользователей UTF8 произвольной длины, которые вряд ли будут использоваться.

Я провел 7 лет в высшем учебном заведении, где нам приходилось придумывать 8-значные имена пользователей для 5000 новых студентов каждый год. К моменту моего отъезда нам удалось придумать уникальные имена для 15-летних студентов. Это можно сделать, мистер smitj510

Вещи, которые сделают вашу жизнь неизмеримо проще:

• Выясните, каков ваш наименьший общий знаменатель, что требует анализа каждой части вашей системы управления идентификацией, чтобы определить, каковы пределы.
  • Эта старая система Solaris 7 устанавливает ограничение в 8 символов.
  • У критических приложений, использующих идентификационные данные, есть свои ограничения, которые вам необходимо учитывать.
    • Возможно, они ожидают, что пользовательские данные из LDAP будут соответствовать уникальному для них «стандарту».
    • Возможно, используемая ими база данных аутентификации может обрабатывать только определенные форматированные данные.
    • Возможно, эта Windows-совместимая система все еще использует SAMAccountName спустя два десятилетия после того, как это перестало быть хорошей идеей.
• Имейте таблицу базы данных со списком Единственного истинного идентификатора (это 8-значное имя учетной записи), со ссылками / полями, перечисляющими альтернативные идентификаторы, например firstname.lastname или что-нибудь еще, что может возникнуть.
  • Стандартное программное обеспечение может делать некоторые действительно странные и недружелюбные к IDM вещи, например использовать числовой идентификатор для имени учетной записи или автоматически генерировать идентификаторы учетной записи на основе данных профиля. Все это тоже входит в таблицу базы данных.
  • Это также помогает людям, в именах которых используются символы, отличные от [a-z | 0-9], такие как Harry O'Neil, или не-ASCII символы, такие как Alžbêta.
• При создании процессов синхронизации учетной записи используйте эту таблицу базы данных, чтобы убедиться, что нужные учетные записи получают правильные обновления. Когда имена меняются (брак, развод, другие), вы хотите, чтобы эти изменения распространялись в нужных местах.
  • Настройте сами фактические базы данных удостоверений, чтобы предотвратить локальные изменения, где это возможно, и бизнес-процесс, чтобы сильно препятствовать этому, когда это невозможно. Положитесь на централизованный процесс синхронизации учетных записей во всем, что вы можете.
• Используйте системы псевдонимов везде, где можете, например, в электронной почте.
• Считайте, что идентификатор из 8 символов является неизменным, поскольку изменение этого поля может вызвать БОЛЬШУЮ боль в сердце у ИТ-персонала, поскольку учетные записи необходимо воссоздавать.
  • Это предполагает идентификатор учетной записи не получено из данных об имени, поскольку брак / развод / постановление суда могут со временем изменить данные об имени.
• Создайте систему исключений, так как они всегда будут.
  • Ужасный развод и 8-значный UID, созданный с помощью имени и данных, вызывают мучительные воспоминания каждый раз, когда вам нужно вводить его? Будьте вежливы со своими пользователями и позвольте механизму для этих изменений, но молчите.
• Сделайте все возможное, чтобы разрешить вход в систему с несколькими именами пользователей в системах, где это возможно.
  • Некоторым нравится их 8-значный uid, другим нравится firstname.lastname@example.com. Будьте гибкими, заводите друзей.
  • Иногда для этого требуется, чтобы ваши веб-системы Единая точка входа рамки как CAS или использовать самл. Вы будете удивлены, узнав, сколько готовых систем могут поддерживать подобные фреймворки SSO, так что не расстраивайтесь.

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

Конкретно ваши вопросы:

• Какое ограничение на длину имени пользователя лучше всего использовать для обеспечения совместимости во всех случаях использования?

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

• Каких персонажей следует избегать?

Это будет зависеть от того, с какими компьютерными системами вы имеете дело. Windows, например, не имеет проблем с точкой в ​​имени пользователя. Фактически, UPN форматируется как адрес электронной почты, что позволяет использовать точку.

Мои дальнейшие мысли:

• Не позволяйте пользователям спрашивать - расскажите им, что такое стандарт, и будьте открыты для бизнеса (а не отдельных пользователей), запрашивая изменения в стандарте по мере изменения требований.
• Сделайте в стандарте «политику исключений», чтобы вы могли помочь бедным Сьюзен Пенингтон и Мэри Атт (из комментариев выше) без необходимости привлекать вице-президента. Сделай так, чтобы ОНО хорошо выглядело, правда?

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

Обязательно выясните, связано ли нажатие на Firstname.Lastname с электронной почтой, а не обязательно с именами для входа. Мне трудно поверить, что пользователь хочет набрать «John.Smith» вместо «jsmith» при входе в систему, но меня гораздо больше поддерживает идея, что он хочет «John.Smith@company.com» "как его адрес электронной почты. Как указывает @Mfinni, у пользователей всегда есть возможность иметь несколько псевдонимов электронной почты, переадресации и т. Д. Простое информирование пользователей о том, что существует возможность отсоединения имени пользователя от адреса электронной почты, может изменить динамику запроса.

Для систем Unix и Linux {firstInitial} {lastname} - это ясно идеальный.

...

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

Одна вещь, о которой следует помнить при установке стандартов именования для разных платформ, - это особая косметическая проблема в ps в Linux (и, возможно, в других операционных системах Unix). Это может вас волновать, а может и нет (но это может настораживать того, кто этого не ожидает ... У меня были люди из службы безопасности, которые подергивались по этому поводу).

Столбец UID будет отображать только до 8 символов имени пользователя. Если имя пользователя длиннее 8 символов, он переключится на печать фактического числового UID. Вы МОЖЕТЕ обойти это, имея собственный формат столбца ps, который содержит поле USER, но ТОЛЬКО если USER является последним столбцом (из моего эмпирического тестирования).

Большинство людей, вероятно, не заботится об этом, но если вы выполняете какую-то обработку вывода ps и ожидаете появления реальных имен пользователей, вам следует быть осторожными с длиной имени (в противном случае вы добавите хаки в свой код. чтобы заставить ps поступать правильно).

Например:

Вот формат столбца по умолчанию для полного списка форматов. Обратите внимание, что мой uid имеет числовой формат, потому что мое имя пользователя> 8 символов.

[tcampbell@tst-agg1 ~]$ ps -f
  UID        PID  PPID  C STIME TTY          TIME CMD
 2108      1368  1367  0 Jan10 pts/3    00:00:00 -bash
 2108     22303  1368  0 12:07 pts/3    00:00:00 ps -f

Давайте воссоздадим его, используя настраиваемый формат столбца. Обратите внимание, что я добавил столбец USER. Обратите внимание, что он также в числовом формате.

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd    
  UID USER      C STIME TT           TIME CMD
 2108 2108      0 Jan10 pts/3    00:00:00 -bash
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty,time,cmd

Переместим ПОЛЬЗОВАТЕЛЯ в конец строки. Он расширяется до "правильного" вывода.

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd,user
  UID USER      C STIME TT           TIME CMD                         USER
 2108 2108      0 Jan10 pts/3    00:00:00 -bash                       tcampbell
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty, tcampbell

Но как только мы добавляем что-то новое в конец списка столбцов, он возвращается к числовой форме.

[tcampbell@tst-agg1 ~]$ ps -o uid,user,c,stime,tty,time,cmd,user,pid
  UID USER      C STIME TT           TIME CMD                         USER       PID
 2108 2108      0 Jan10 pts/3    00:00:00 -bash                       2108      1368
 2108 2108      0 12:05 pts/3    00:00:00 ps -o uid,user,c,stime,tty, 2108     21756

[несколько букв от имени] [несколько букв от фамилии] [nnn]

foreg: Если имя Билл Гейтс, вы можете использовать ' biga00 ' или bilgat000

если придет следующий билл гейтс, для него это будет biga01 или bilgat001

Что ж, с точки зрения эксплуатации, администрирования и обслуживания (OAM) имя пользователя должно быть легко различимо. Однако с точки зрения бизнеса, имя пользователя (псевдоним электронной почты) должно легко запоминаться или отозваться другими.

Это может быть так:

• first.last.index@domain
• первый (начальный) .last.index @ домен