Thực tiễn tốt nhất trong tiêu chuẩn tên người dùng: Tránh các vấn đề

Tôi quan tâm đến việc tìm hiểu trải nghiệm của mọi người với tên người dùng chuẩn là gì. Tôi đã luôn ở những nơi đã sử dụng {firstInitial} {lastname} (đôi khi có giới hạn độ dài). Bây giờ tôi đã có những người dùng muốn {Firstname}. {Lastname} - và bây giờ có thể giai đoạn này có thể gây ra sự cố.

Đặc biệt:

• Giới hạn độ dài tên người dùng tốt nhất để sử dụng để duy trì khả năng tương thích trên tất cả các mục đích sử dụng là gì?
• Những nhân vật nên tránh?

CẬP NHẬT: Lý do tôi không đề cập đến chi tiết cụ thể là tôi muốn nói chung đủ để xử lý bất cứ điều gì có thể xảy ra trong tương lai. Tuy nhiên, đó có thể là quá chung chung của một yêu cầu (bất cứ điều gì cũng có thể xảy ra, phải không?).

Đây là môi trường của chúng tôi: Ubuntu Server Lucid Lynx 10.04 LTS, Red Hat Enterprise Linux 5.6 trở lên, Windows Server 2003 và Windows 2000 Server (với Active Directory trong Windows 2000 Native Mode), Zimbra 7.x cho thư và OpenLDAP ở gần Tương lai.

CẬP NHẬT: Tôi nên đề cập (cho đầy đủ) rằng tôi đã thấy câu hỏi này (mặc dù nó không trả lời câu hỏi của tôi) và bài đăng trên web này , cả hai đều rất nhiều thông tin.

Đây là một vấn đề mãn tính với các hệ thống quản lý danh tính lớn đang cố gắng gắn kết các hệ thống không đồng nhất với nhau. Lúc nào cũng vậy, bạn sẽ bị giới hạn ở mẫu số chung thấp nhất, mà tất cả quá thường xuyên là giới hạn số ASCII-alpha 8 ký tự nhờ một số hệ thống giống như Unix có thể ở đâu đó trong ruột của trung tâm dữ liệu. Những hệ thống hiện đại lạ mắt này có thể lấy tên người dùng UTF8 có độ dài tùy ý không có khả năng được sử dụng.

Tôi đã dành 7 năm tại một tổ chức giáo dục đại học nơi chúng tôi phải tìm ra tên người dùng 8 ký tự cho 5000 sinh viên mới mỗi năm. Chúng tôi đã cố gắng đưa ra những cái tên độc đáo cho 15 năm sinh viên khi tôi rời đi. Điều này có thể được thực hiện, ông smitj510

Những điều sẽ làm cho cuộc sống của bạn dễ dàng hơn nhiều:

• Chỉ ra mẫu số chung thấp nhất của bạn là gì, yêu cầu phân tích mọi bộ phận trong hệ thống quản lý danh tính của bạn để khám phá giới hạn là gì.
  • Hệ thống Solaris 7 cũ đó đang buộc giới hạn 8 ký tự.
  • Các ứng dụng quan trọng sử dụng dữ liệu nhận dạng có giới hạn riêng mà bạn sẽ phải xem xét.
    • Có lẽ họ mong đợi dữ liệu người dùng từ LDAP tuân thủ 'tiêu chuẩn' duy nhất cho họ.
    • Có lẽ cơ sở dữ liệu xác thực họ sử dụng chỉ có thể xử lý dữ liệu được định dạng nhất định.
• Có một bảng cơ sở dữ liệu với một danh sách Định danh Một Đúng (tên tài khoản 8 ký tự đó), với các liên kết / trường liệt kê ID thay thế giống như firstname.lastnamehoặc bất kỳ thứ gì khác có thể xuất hiện.
  • Phần mềm sẵn có có thể thực hiện một số điều thực sự kỳ lạ và không thân thiện với IDM như sử dụng ID số cho tên tài khoản hoặc tự động tạo ID tài khoản dựa trên dữ liệu hồ sơ. Tất cả những gì đi vào bảng cơ sở dữ liệu quá.
  • Điều này cũng giúp những người có các ký tự không [az | 0-9] trong tên của họ như Harry O'Neil hoặc không phải ASCII như Alžbêta.
• Khi bạn xây dựng các quy trình đồng bộ hóa tài khoản của mình, hãy tận dụng bảng cơ sở dữ liệu đó để đảm bảo rằng các tài khoản phù hợp sẽ nhận được các bản cập nhật phù hợp. Khi tên thay đổi (kết hôn, ly hôn, những người khác) bạn muốn những thay đổi đó lan truyền đến đúng nơi.
  • Tự cấu hình cơ sở dữ liệu nhận dạng thực tế để ngăn chặn các thay đổi cục bộ nếu có thể và quy trình kinh doanh không khuyến khích mạnh mẽ khi không thể. Dựa vào quá trình đồng bộ hóa tài khoản trung tâm cho mọi thứ bạn có thể.
• Tận dụng các hệ thống bí danh bất cứ nơi nào bạn có thể, chẳng hạn như trong email.
• Hãy xem xét ID 8 ký tự không thay đổi, vì việc thay đổi trường đó có thể gây ra rất nhiều đau khổ trong đội ngũ nhân viên CNTT khi các tài khoản phải được tạo lại.
  • Điều này cho thấy ID tài khoản không xuất phát từ dữ liệu tên, vì hôn nhân / ly hôn / lệnh của tòa án có thể thay đổi dữ liệu tên theo thời gian.
• Có một hệ thống tại chỗ cho các trường hợp ngoại lệ, vì sẽ luôn có một số.
  • Ly hôn khủng khiếp và dữ liệu tên được tạo ra 8-char UID mang lại những ký ức đau khổ mỗi khi bạn phải nhập nó? Hãy tốt với người dùng của bạn và cho phép một cơ chế cho những thay đổi này, nhưng hãy giữ im lặng.
• Làm những gì bạn có thể để cho phép nhiều thông tin đăng nhập tên người dùng trong các hệ thống có tùy chọn
  • Một số người thích uid 8 ký tự của họ, những người khác thích Firstname.lastname@example.com. Hãy linh hoạt, kết bạn.
  • Đôi khi, điều này đòi hỏi phải đặt trước các hệ thống dựa trên web của bạn với khung đăng nhập một lần như CAS . Bạn sẽ ngạc nhiên khi có bao nhiêu hệ thống kệ có thể hỗ trợ các khung SSO như thế này, vì vậy đừng nản lòng.

Điều đó có nghĩa là, coi nó như một vấn đề cơ sở dữ liệu bởi vì đó là những gì nó là. Chọn khóa chính để tương thích tối đa với các hệ thống của bạn (có thể là 8 ký tự), xây dựng bảng tra cứu để cho phép các hệ thống dịch ID cục bộ sang khóa chính và thiết kế các hệ thống đồng bộ hóa dữ liệu của bạn để xử lý các ID khác nhau.

Câu hỏi của bạn cụ thể:

• Giới hạn độ dài tên người dùng tốt nhất để sử dụng để duy trì khả năng tương thích trên tất cả các mục đích sử dụng là gì?

Không có những điều như vậy. Chỉ có "sử dụng" của bạn, có thể bao gồm các sử dụng trong tương lai của bạn. Chúng tôi không biết đó là những gì.

• Những nhân vật nên tránh?

Điều này sẽ phụ thuộc vào hệ thống máy tính mà bạn đang xử lý. Windows, ví dụ, không có vấn đề với một khoảng thời gian trong tên người dùng. Trong thực tế, UPN được định dạng như một địa chỉ email, cho phép một khoảng thời gian.

Suy nghĩ thêm của tôi:

• Đừng để người dùng của bạn hỏi - hãy cho họ biết tiêu chuẩn là gì và hãy cởi mở với doanh nghiệp (không phải người dùng cá nhân) yêu cầu thay đổi tiêu chuẩn khi yêu cầu thay đổi.
• Thực hiện một "chính sách ngoại lệ" trong tiêu chuẩn, để bạn có thể giúp đỡ Susan Penington và Mary Utt tội nghiệp (từ các bình luận ở trên) mà không cần phải có phó chủ tịch. Làm cho CNTT trông tốt, phải không?

Kinh nghiệm của tôi là, đối với một doanh nghiệp đủ lớn, bất kỳ quyết định nào bạn đưa ra sẽ luôn có vấn đề. Ngay cả khi nó hoạt động ngày hôm nay, luôn có hệ thống bạn triển khai vào ngày mai có vấn đề với tiêu chuẩn trước đó (vấn đề về độ dài, vấn đề về nhân vật, v.v.).

Hãy chắc chắn để tìm hiểu xem việc đẩy cho Firstname.Lastname có liên quan đến email và không nhất thiết phải đăng nhập tên. Tôi cảm thấy khó tin rằng người dùng muốn gõ "John.Smith" thay vì "jsmith" khi đăng nhập, nhưng tôi bị bán nhiều hơn với ý tưởng rằng anh ta muốn "John.Smith@company.com "Như địa chỉ email của anh ấy. Như @Mfinni chỉ ra, luôn có tùy chọn cho người dùng có các bí danh email khác nhau, chuyển tiếp, v.v. Chỉ cần cho người dùng biết rằng tùy chọn tồn tại để tách cặp tên người dùng khỏi địa chỉ email của họ có thể thay đổi động của yêu cầu.

Đối với các hệ thống Unix và Linux, {firstInitial} {lastname} rõ ràng là lý tưởng.

...

vì những lý do nên rõ ràng từ tên được liên kết với tài khoản này.

Một điều cần lưu ý khi thiết lập các tiêu chuẩn đặt tên trên các nền tảng là một vấn đề thẩm mỹ cụ thể trong ps trong Linux (và có thể cả các hệ điều hành Unix khác). Bạn có thể hoặc không quan tâm đến điều này (nhưng nó có thể đáng báo động cho một người không mong đợi nó ... Tôi đã có những người bảo mật co giật về điều này).

Cột UID sẽ chỉ hiển thị tối đa 8 ký tự của tên người dùng. Nếu tên người dùng dài hơn 8 ký tự, nó sẽ chuyển sang in UID số thực tế. Bạn CÓ THỂ khắc phục điều này bằng cách có định dạng cột ps tùy chỉnh có chứa trường USER, nhưng CHỈ nếu USER là cột cuối cùng (từ thử nghiệm thực nghiệm của tôi).

Hầu hết mọi người có thể không quan tâm đến điều này, nhưng nếu bạn đang thực hiện một số cách xử lý đầu ra ps và mong muốn tên người dùng thực sự xuất hiện, bạn nên cẩn thận với độ dài tên của mình (nếu không, bạn sẽ bị hack trong mã của mình để làm cho ps làm điều đúng).

Ví dụ:

Đây là định dạng cột mặc định cho danh sách định dạng đầy đủ. Lưu ý rằng uid của tôi ở định dạng số vì tên người dùng của tôi> 8 ký tự.

[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

Hãy tạo lại nó bằng định dạng cột tùy chỉnh. Lưu ý rằng tôi đã thêm cột USER. Lưu ý rằng đó cũng là định dạng số.

[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

Hãy di chuyển USER đến cuối dòng. Nó được mở rộng đến đầu ra "đúng".

[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

Nhưng, ngay khi chúng ta thêm một cái gì đó mới vào cuối danh sách cột, nó sẽ trở lại dạng số.

[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

[một số chữ cái từ tên đầu tiên] [một số chữ cái từ tên họ] [nnn]

foreg: Nếu tên là Bill Gates, bạn có thể sử dụng ' biga00 ' hoặc bilgat000

nếu cổng hóa đơn tiếp theo đến, nó sẽ là 'biga01' hoặc bilgat001 'cho anh ta

Vâng, từ quan điểm Hoạt động, Quản trị và Bảo trì (OAM), tên người dùng cần phải được phân biệt dễ dàng. Tuy nhiên, từ quan điểm kinh doanh, tên người dùng (a / k / bí danh email) phải dễ dàng được người khác nhớ hoặc nhớ lại.

Nó có thể giống như:

• đầu tiên.last.index@domain
• đầu tiên (ban đầu) .last.index @ domain