Najlepsze praktyki w standardach nazw użytkowników: unikanie problemów

Chcę dowiedzieć się, jakie są ludzkie doświadczenia ze standardowymi nazwami użytkowników. Zawsze byłem w miejscach, w których używałem {firstInitial} {nazwisko} (czasami z ograniczeniem długości). Teraz mam użytkowników, którzy chcą {imię}. {Nazwisko} - i teraz okazuje się, że kropka może powodować problemy.

Konkretnie:

• Jaki jest najlepszy limit długości nazwy użytkownika, aby zachować zgodność we wszystkich zastosowaniach?
• Jakich postaci należy unikać?

AKTUALIZACJA: Powodem, dla którego nie wspomniałem o szczegółach, jest to, że chciałem być na tyle ogólny, aby poradzić sobie ze wszystkim, co może się wydarzyć w przyszłości. Może to jednak być zbyt ogólny wymóg (wszystko może się zdarzyć, prawda?).

Oto nasze środowisko: Ubuntu Server Lucid Lynx 10.04 LTS, Red Hat Enterprise Linux 5.6 i nowsze wersje, Windows Server 2003 i Windows 2000 Server (z Active Directory w Windows 2000 Native Mode), Zimbra 7.x dla poczty i OpenLDAP w najbliższej przyszłość.

AKTUALIZACJA: Powinienem wspomnieć (dla kompletności), że widziałem to pytanie (choć nie odpowiadało na moje zadane pytanie), a także ten post internetowy , które były bardzo pouczające.

Jest to chroniczny problem z dużymi systemami zarządzania tożsamością, które próbują skleić ze sobą systemy heterogeniczne. Niezmiennie będziesz ograniczony do najniższego wspólnego mianownika, który zbyt często jest 8-znakowym limitem alfanumerycznym ASCII dzięki niektórym (prawdopodobnie starszym) systemowi uniksowemu gdzieś w trzewiach centrum danych. Te fantazyjne nowoczesne systemy mogą przyjmować dowolne długości nazw użytkowników UTF8, których użycie jest mało prawdopodobne.

Spędziłem 7 lat w szkole wyższej, gdzie musieliśmy wymyślić 8-znakowe nazwy użytkowników dla 5000 nowych studentów każdego roku. Zanim wyjechałem, udało nam się wymyślić unikalne nazwiska dla 15 lat studentów. Można to zrobić, panie smitj510

Rzeczy, które znacznie ułatwią ci życie:

• Dowiedz się, jaki jest Twój najniższy wspólny mianownik, który wymaga przeanalizowania każdej części systemu zarządzania tożsamością, aby ustalić, jakie są granice.
  • Ten stary system Solaris 7 wymusza limit 8 znaków.
  • Krytyczne aplikacje wykorzystujące dane tożsamości mają swoje własne ograniczenia, które należy wziąć pod uwagę.
    • Być może oczekują, że dane użytkowników z LDAP będą zgodne z unikalnym dla nich „standardem”.
    • Być może używana przez nich baza danych uwierzytelniania obsługuje tylko niektóre sformatowane dane.
• Mieć tabelę bazy danych z listą One True Identifier (ta 8-znakowa nazwa konta), z linkami / polami zawierającymi alternatywne identyfikatory podobne firstname.lastnamelub cokolwiek innego, co mogłoby się pojawić.
  • Gotowe oprogramowanie może robić naprawdę dziwne i nieprzyjazne dla IDM rzeczy, takie jak używanie identyfikatora numerycznego dla nazwy konta lub automatyczne generowanie identyfikatorów konta na podstawie danych profilu. Wszystko to trafia także do tabeli bazy danych.
  • Pomaga to również osobom z imionami spoza [az | 0-9] w nazwiskach, takich jak Harry O'Neil, lub spoza ASCII, takimi jak Alžbêta.
• Podczas budowania procesów synchronizacji kont skorzystaj z tabeli bazy danych, aby mieć pewność, że odpowiednie konta otrzymają odpowiednie aktualizacje. Kiedy zmieniają się nazwiska (małżeństwo, rozwód, inne), chcesz, aby zmiany te rozpowszechniły się we właściwych miejscach.
  • Skonfiguruj same rzeczywiste bazy danych tożsamości, aby w miarę możliwości zapobiec lokalnym zmianom, a proces biznesowy zdecydowanie zniechęcaj, gdy nie jest to możliwe. Polegaj na centralnym procesie synchronizacji konta dla wszystkiego, co możesz.
• Wykorzystaj systemy aliasów, gdziekolwiek możesz, na przykład w wiadomości e-mail.
• Rozważ niezmienne 8-znakowe ID, ponieważ zmiana tego pola może wywołać wiele bólu serca wśród pracowników IT, ponieważ trzeba odtworzyć konta.
  • Sugeruje to, że identyfikator konta nie pochodzi z danych imienia, ponieważ małżeństwo / rozwód / orzeczenie sądowe mogą z czasem zmienić dane imienia i nazwiska.
• Przygotuj system wyjątków, ponieważ zawsze będzie jakiś.
  • Okropny rozwód i ten 8-znakowy identyfikator użytkownika generowany na podstawie danych przywołuje szokujące wspomnienia za każdym razem, gdy trzeba go wprowadzić? Bądź miły dla swoich użytkowników i pozwól mechanizmowi tych zmian, ale bądź cicho.
• Zrób, co możesz, aby umożliwić wielokrotne logowanie się do nazwy użytkownika w systemach, w których jest to możliwe
  • Niektórzy ludzie lubią swój 8-znakowy identyfikator użytkownika, inni jak imię.nazwa@example.com. Bądź elastyczny, zaprzyjaźnij się.
  • Czasami wymaga to przestawienia systemów internetowych na strukturę jednokrotnego logowania , taką jak CAS . Zdziwisz się, ile gotowych systemów może obsługiwać takie struktury SSO, więc nie zniechęcaj się.

Innymi słowy, traktuj to jak problem z bazami danych, ponieważ tak właśnie jest. Wybierz klucz podstawowy, aby uzyskać maksymalną kompatybilność z systemami (prawdopodobnie 8 znaków), zbuduj tabelę przeglądową, aby umożliwić systemom translację lokalnych identyfikatorów na klucz podstawowy i zaprojektuj systemy synchronizacji danych do obsługi różnych identyfikatorów.

Twoje pytania w szczególności:

• Jaki jest najlepszy limit długości nazwy użytkownika, aby zachować zgodność we wszystkich zastosowaniach?

Nie ma takiej rzeczy. Są tylko „twoje” zastosowania, które mogą obejmować twoje przyszłe zastosowania. Nie mamy pojęcia, co to jest.

• Jakich postaci należy unikać?

Będzie to zależeć od systemów komputerowych, z którymi masz do czynienia. Na przykład system Windows nie ma problemów z kropką w nazwie użytkownika. W rzeczywistości UPN jest sformatowany jak adres e-mail, co pozwala na kropkę.

Moje dalsze przemyślenia:

• Nie pozwól użytkownikom pytać - powiedz im, jaki jest standard, i bądź otwarty na firmę (nie indywidualnych użytkowników), która żąda zmian w standardzie w miarę zmiany wymagań.
• Opracuj „zasadę wyjątku” w standardzie, aby pomóc biednej Susan Penington i Mary Utt (z powyższych komentarzy) bez konieczności angażowania wiceprezydenta. Spraw, by IT wyglądało dobrze, prawda?

Z mojego doświadczenia wynika, że ​​w przypadku wystarczająco dużego przedsiębiorstwa każda decyzja, którą podejmiesz, zawsze będzie miała problemy. Nawet jeśli działa dzisiaj, zawsze będzie system, który wdrażasz jutro, który ma problemy z poprzednim standardem (problemy z długością, problemy z postaciami itp.).

Upewnij się, aby dowiedzieć się, czy wypychanie Firstname.Lastname odnosi się do wiadomości e-mail i niekoniecznie nazw logowania. Trudno mi uwierzyć, że użytkownik chce wpisać „John.Smith” zamiast „jsmith” podczas logowania, ale jestem o wiele bardziej przekonany, że chce „John.Smith@company.com ”jako jego adres e-mail. Jak wskazuje @Mfinni, zawsze istnieje możliwość, aby użytkownicy mieli wiele aliasów e-mail, przekazuje dalej itp. Po prostu powiadomienie użytkowników, że istnieje opcja oddzielenia nazwy użytkownika od adresu e-mail, może zmienić dynamikę żądania.

W systemach Unix i Linux, {firstInitial} {lastname} jest wyraźnie idealny.

...

z powodów, które powinny wynikać z nazwy powiązanej z tym kontem.

Jedną z rzeczy, o których należy pamiętać przy ustalaniu standardów nazewnictwa na różnych platformach, jest szczególny problem kosmetyczny w ps w Linuksie (i ewentualnie w innych systemach uniksowych). Możesz o to dbać lub nie (ale może to być niepokojące dla kogoś, kto się tego nie spodziewa ... Miałem kłopoty z ochroną).

Kolumna UID wyświetli tylko do 8 znaków nazwy użytkownika. Jeśli nazwa użytkownika jest dłuższa niż 8 znaków, przejdzie do drukowania rzeczywistego numerycznego UID. Możesz obejść ten problem, mając niestandardowy format kolumny ps, który zawiera pole USER, ale TYLKO jeśli USER jest ostatnią kolumną (z moich testów empirycznych).

Większość ludzi prawdopodobnie nie przejmuje się tym, ale jeśli robisz jakieś przetwarzanie danych wyjściowych ps i spodziewasz się, że pojawią się prawdziwe nazwy użytkowników, powinieneś uważać na długość swoich nazw (w przeciwnym razie wstawisz hacki w kodzie aby ps zrobił właściwą rzecz).

Na przykład:

Oto domyślny format kolumny dla pełnego wykazu formatów. Pamiętaj, że mój identyfikator użytkownika ma format numeryczny, ponieważ moja nazwa użytkownika ma> 8 znaków.

[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

Utwórzmy go ponownie, używając niestandardowego formatu kolumny. Pamiętaj, że dodałem kolumnę USER. Pamiętaj, że jest on również w formacie numerycznym.

[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

Przenieśmy USER na koniec linii. Zostaje rozwinięty do „właściwej” mocy wyjściowej.

[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

Ale gdy tylko dodamy coś nowego na końcu listy kolumn, powraca do postaci liczbowej.

[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

[niektóre litery od imienia] [niektóre litery od nazwiska] [nnn]

foreg: Jeśli nazywa się Bill Gates, możesz użyć „ biga00 ” lub bilgat000

jeśli przyjdzie kolejna bramka, będzie to dla niego „biga01” lub bilgat001

Z punktu widzenia operacji, administracji i konserwacji (OAM) nazwę użytkownika należy łatwo odróżnić. Jednak z biznesowego punktu widzenia nazwa użytkownika (alias e / k / e-mail) musi być łatwo zapamiętana lub przywołana przez innych.

Może to być:

• first.last.index@domain
• first (initial) .last.index @ domain