An toàn DB2 UDB, Phần 2: Hiểu các trình cắm thêm an toàn của DB2 cho Linux, UNIX và Windows

Tìm hiểu về các trình cắm thêm an toàn của DB2® cho Linux®, UNIX®, và Windows® (DB2) IBM®, một tính năng mới được giới thiệu trong Phiên bản 8.2. Bài này giải thích các trình cắm thêm an toàn làm gì và dạy bạn cách chạy và viết trình cắm thêm an toàn riêng của bạn.

Kevin Yeung-Kuen See, Phát triển phần mềm, IBM

Kevin See, CISSP là một nhà phát triển phần mềm cao cấp tại phòng thí nghiệm Toronto của IBM đang làm về FVT của DB2 cho nhóm nhân (Kernel). Trước đó, ông làm trong nhóm Phát triển an toàn DB2 và nhóm phát triển Catalog và SQL của DB2. Ông đã làm việc với IBM trong chín năm. Hiện ông đang tập trung vào các mô hình kiểm soát truy cập và xác thực. Ông đã nhận bằng thạc sỹ toán (Kỹ thuật phần mềm) của trường Đại học Waterloo và bằng cử nhân khoa học máy tính (B.C.S) của trường Đại học Acadia. Ông là một người phát triển các giải pháp có chứng chỉ IBM về XML và các công nghệ liên quan, và là chuyên gia về các giải pháp có chứng chỉ DB2 (DBA cho OS/390, DBA cho Linux/Unix/Windows, và phát triển ứng dụng họ DB2). Ông cũng là một chuyên gia An toàn về các hệ thống thông tin có chứng chỉ ISC2.



Sushma Narisetty, Sinh viên năm 4, IBM

Sushma Narisetty là một sinh viên Kỹ thuật điện năm thứ tư tại trường Đại học Toronto. Cô là một người phát triển thông tin tại phòng thí nghiệm Toronto của IBM trước khi rời đi để hoàn thành văn bằng của mình. Cô là một Quản trị viên Cơ sở dữ liệu và người phát triển ứng dụng có chứng chỉ IBM về DB2 Universal Database V8.1cho Linux, UNIX, và Windows.



Raul Chong, Nhà tư vấn cơ sở dữ liệu, IBM Toronto Laboratory

Raul Chong là một nhà tư vấn cơ sở dữ liệu của Phòng thí nghiệm Toronto của IBM và chủ yếu làm với Các đối tác kinh doanh của IBM. Raul đã làm việc trong sáu năm tại IBM, trong thời gian này có ba năm làm về Hỗ trợ kỹ thuật DB2 9.1 và ba năm làm tư vấn chuyên về phát triển và di chuyển cơ sở dữ liệu ứng dụng từ các RDBMS khác sang DB2 9.1.


Cấp độ đóng góp cho developerWorks của
        tác giả

Il-Sung Lee, Quản lý chương trình, Microsoft Corporation

Lee Il-Sung, P. Eng, là một người quản lý Chương trình về Microsoft SQL Server. Ông là một Kỹ sư Phần mềm cao cấp tại phòng thí nghiệm Toronto của IBM và đã làm việc với IBM trong bảy năm trước khi gia nhập Microsoft. Ông là một thành viên của nhóm Phát triển an toàn DB2, ở đây các lĩnh vực quan tâm của ông bao gồm Kerberos, các mô hình xác thực, và khai thác lỗ hổng mã. Ông nhận được bằng Thạc sỹ Kỹ thuật của trường Đại học McGill và một bằng Cử nhân khoa học (B.A.Sc) của trường Đại học British Columbia, cả hai đều về Kỹ thuật điện tử.



18 05 2011 (Xuất bản lần đầu tiên vào ngày 30 12 2011)

Giới thiệu

Phần 1 của loạt bài này trình bày mô hình an toàn của DB2, và thảo luận cách các tài khoản người dùng và nhóm tương tác với DB2 cho Linux, UNIX, và Windows (DB2). Phần 2 của loạt bài này tập trung vào các trình cắm thêm an toàn của DB2, phương thức mới thực hiện an toàn của DB2. Bài này thảo luận về mọi thứ bạn cần biết để có một sự hiểu biết tốt về các trình cắm thêm an toàn của DB2, các kiểu trình cắm thêm an toàn khác nhau, tại sao chúng lại quan trọng, và cách sử dụng chúng. Bài này cũng gồm các chương trình trình cắm thêm an toàn mẫu, và cho bạn thấy cách thực hiện chúng từng bước một. Sau khi đọc bài này, bạn sẽ có thể viết một trình cắm thêm an toàn cơ bản và tránh các lỗi thường gặp khi làm việc với chúng.


Các trình cắm thêm an toàn DB2 — Bức tranh tổng thể

Các trình cắm thêm an toàn là các thư viện có thể tải một cách động mà DB2 gọi ra khi thực hiện xác thực hoặc tra tìm thành viên nhóm cho người dùng. Trước phiên bản 8.2, một phương tiện bên ngoài thay cho DB2 đã quản lý các hoạt động này, ví dụ như hệ điều hành, một bộ điều khiển miền, hoặc một hệ thống an toàn Kerberos. Hình 1 cung cấp các kịch bản minh họa cách an toàn DB2 đã làm việc trước phiên bản 8.2. Các phần tiếp theo mô tả những gì đã thay đổi với phiên bản 8.2.

Hình 1. Các kịch bản an toàn
Các kịch bản an toàn

Hình 1 minh họa bốn kịch bản an toàn:

  1. Các cân nhắc về an toàn khi kết nối với một cơ sở dữ liệu từ một hệ thống máy khách đến một hệ thống máy chủ
    Ở phía bên trái của Hình 1, một người dùng đã ban hành câu lệnh connect to mydb user raul using raulpsw (kết nối với người dùng mydb là raul bằng cách sử dụng raulpsw) từ cửa sổ Bộ xử lý dòng lệnh (CLP) của một hệ thống máy khách DB2 để kết nối với cơ sở dữ liệu mydb, lưu trú trên máy chủ DB2 Aries. Máy khách DB2 giao tiếp với máy chủ và thỏa thuận sử dụng phương thức xác thực nào. Để đơn giản, chúng ta hãy giả sử máy khách sử dụng phương thức xác thực do máy chủ trả về. Trong hình này, AUTHENTICATION được thiết lập cho SERVER. Điều này có nghĩa là hệ điều hành máy chủ (I) sẽ thực hiện xác thực bằng cách kiểm tra xem ID và mật khẩu người dùng đã cấp có phù hợp theo các giá trị được lưu trữ trong cơ sở dữ liệu an toàn của hệ điều hành không. Một khi người dùng được xác thực, DB2 sẽ lấy thông tin thành viên nhóm từ hệ điều hành. Từ thời điểm tiếp theo, DB2 sẽ không còn sử dụng ID hoặc mật khẩu người dùng cho bất kỳ việc kiểm tra nào nữa, thay vào đó, DB2 sẽ sử dụng ID ủy quyền (authID). Nói chung, một authID là phiên bản chữ hoa của một ID người dùng.
  2. Các cân nhắc về an toàn khi thực hiện các câu lệnh SQL sau khi kết nối vào cơ sở dữ liệu
    Phần dưới cùng bên trái của Hình 1 cho thấy một câu lệnh SELECT được ban hành trong lúc đã kết nối với cơ sở dữ liệu mydb bằng authID là RAUL. Trong trường hợp này, phương tiện chức năng an toàn DB2 bên trong thực hiện kiểm tra ủy quyền bằng cách xem lại các bảng Catalog của DB2 để xác nhận rằng authID RAUL đã được cấp đặc quyền SELECT từ bảng KEVIN.TABLE1. Nếu authID RAUL và PUBLIC (công khai) vẫn chưa được cấp đặc quyền này, DB2 sẽ kiểm tra xem người dùng này có là một phần của một trong các nhóm đặc biệt như SYSADM, SYSCTRL, SYSMAINT hoặc SYSMON không. Có các tham số (dbm cfg) cấu hình của trình quản lý cơ sở dữ liệu cho mỗi nhóm, và bạn có thể thiết lập các tham số này tới giá trị của một nhóm hệ điều hành. Vào lúc kết nối, thông tin nhóm về người dùng được lấy ra từ hệ điều hành và lưu trữ trong bộ nhớ nhanh. Sau đó DB2 sẽ kiểm tra xem authID RAUL có là một phần của một trong các nhóm này không bằng cách xem lại dữ liệu (II) đã lưu trong bộ nhớ nhanh này. Ví dụ, nếu authID là một phần của nhóm SYSADM, câu lệnh SELECT có thể tiếp tục, ngược lại sẽ trả về một thông báo lỗi (SQLCODE -551).
  3. Các cân nhắc về an toàn khi thực hiện an toàn tại máy khách
    Nếu AUTHENTICATION đã được thiết lập tới CLIENT trong Hình 1, hệ điều hành ở máy tính khách này sẽ thực hiện xác thực (III). Việc kiểm tra ủy quyền với câu lệnh SELECT sẽ được thực hiện như trước: DB2 sẽ xác minh xem authID RAUL có đặc quyền SELECT với bảng KEVIN.TABLE1 trong các bảng cơ sở dữ liệu DB2 Catalog không. Nếu authID RAUL và PUBLIC không có đặc quyền này, thì thực hiện kiểm tra thành viên nhóm. Vào lúc kết nối, thông tin thành viên nhóm từ máy khách được chuyển đến và lưu trữ trong bộ nhớ nhanh tại máy chủ.
  4. Các cân nhắc về an toàn khi ban hành các lệnh mức cá thể
    Tại máy chủ trong Hình 1, chủ sở hữu cá thể DB2 là db2inst1 đưa ra lệnh db2stop. DB2 kiểm tra xem người dùng đã đăng nhập hiện tại có thuộc nhóm được định nghĩa trong SYSADM_GROUP, SYSCTRL_GROUP, hoặc SYSMAINT_GROUP (IV) không. Nếu ID người dùng thuộc về bất kỳ một trong các nhóm này, lệnh db2stop sẽ thực hiện thành công. Nếu không, sẽ trả về một thông báo lỗi. Tùy thuộc vào hoạt động mức cá thể, người dùng có thể là một phần của các nhóm SYSADM, SYSCTRL, SYSMAINT hoặc SYSMON.

Trong mỗi kịch bản, hệ điều hành được gọi để thực hiện các việc kiểm tra an toàn. Bắt đầu với phiên bản 8.2, có thể sử dụng các trình cắm thêm an toàn trong mỗi tình huống này. Thay vì luôn gọi hệ điều hành, có thể gọi một trình cắm thêm máy chủ và nhóm trong kịch bản 1, có thể gọi một trình cắm thêm nhóm trong kịch bản 2, và có thể gọi các trình cắm thêm máy khách và nhóm trong kịch bản 3 và 4.

Ví dụ này giới thiệu ba thể loại trình cắm thêm an toàn:

  • Trình cắm thêm an toàn xác thực phía máy chủ (trình cắm thêm xác thực phía máy chủ).
  • Trình cắm thêm an toàn xác thực phía máy khách (trình cắm thêm xác thực phía máy khách).
  • Trình cắm thêm an toàn tra tìm thành viên nhóm (trình cắm thêm nhóm).

Trình cắm thêm xác thực máy chủ thực hiện xác thực trên máy chủ cơ sở dữ liệu. Nó cũng được sử dụng để kiểm tra xem trình cắm thêm có biết authID không. Ví dụ, hãy xem xét câu lệnh SQL grant select on table user1.t1 to FOO, (cấp chọn trên bảng user1.t1 cho FOO), ở đây DB2 không biết liệu FOO có là một người dùng hoặc nhóm không. Trong trường hợp này, DB2 tra cứu tất cả các trình cắm thêm phía máy chủ và các trình cắm thêm thành viên nhóm để kiểm tra xem FOO có là một người dùng, một nhóm, không rõ, hoặc cả hai không, để nó có thể đáp ứng cho phù hợp với câu lệnh SQL.

Trình cắm thêm xác thực máy khách thực hiện xác thực trên máy khách. Nó cũng được dùng để thực hiện xác thực cục bộ mức cá thể trên máy chủ cơ sở dữ liệu khi thực hiện các lệnh mức cá thể (chẳng hạn như db2start, db2stop, db2trc, update dbm cfg, và v.v..) Vì vậy, phổ biến là xem cả hai trình cắm thêm xác thực máy khách và trình cắm thêm xác thực máy chủ được chỉ rõ trên một máy chủ cơ sở dữ liệu.

Trình cắm thêm nhóm thực hiện tra tìm thành viên nhóm trên cả máy khách lẫn máy chủ cơ sở dữ liệu. Nó cũng được dùng để kiểm tra xem trình cắm thêm có biết authID không.

Mỗi trình cắm thêm an toàn có chứa một tập các API mà bạn cần thực hiện. DB2 cung cấp cơ sở hạ tầng của trình cắm thêm an toàn và một số trình cắm thêm an toàn mặc định. Để dành việc thực hiện trình cắm thêm an toàn tùy chỉnh cho bạn tự quyết định.


Các ưu điểm của việc sử dụng trình cắm thêm an toàn

Các ưu điểm chính của việc sử dụng cơ chế an toàn mới của DB2 là tính linh hoạt và tính mở rộng mà các trình cắm thêm an toàn có thể cung cấp. Bạn có thể tùy chỉnh các cơ chế an toàn để đáp ứng các nhu cầu cá nhân của bạn, thay vì dựa vào một phương tiện chức năng tiêu chuẩn như hệ điều hành. Ví dụ, trước phiên bản 8.2, bất kỳ người dùng hệ điều hành nào đã đăng nhập vào hệ thống đều có thể ban hành một câu lệnh kết nối mà không cần vượt qua kiểm tra ID và mật khẩu người dùng (được gọi là một kết nối ngầm định), và giả sử ID người dùng có đặc quyền CONNECT của DB2, thì anh ta có thể kết nối thành công. Với các trình cắm thêm, bạn có thể thay đổi hành vi này sao cho không cho phép kết nối ngầm định.

LDAP là một ví dụ khác. LDAP hiện không được hỗ trợ như là một phương thức xác thực trong DB2; tuy nhiên, bạn luôn có thể thực hiện nó bằng cách sử dụng một trình cắm thêm an toàn. Một ví dụ đơn giản được trình bày sau trong bài viết này, khi sử dụng Microsoft Active Directory (Thư mục tích cực của Microsoft) để thực hiện xác thực dựa trên LDAP.

Các trình cắm thêm an toàn được thực hiện cho mỗi cá thể, do đó bạn có thể tạo ra các cá thể khác nhau, và có các công cụ trình cắm thêm an toàn khác nhau. Hình 2 cho thấy tính linh hoạt và tính mở rộng được cung cấp bằng cách sử dụng các trình cắm thêm an toàn.

Hình 2. Các trình cắm thêm an toàn DB2: Tính linh hoạt và tính mở rộng
Các trình cắm thêm an toàn DB2: Tính linh hoạt và tính mở rộng

Các trình cắm thêm an toàn mặc định

Sau khi cài đặt hoặc chuyển đổi sang phiên bản 8.2 của DB2, bạn không cần viết mã của trình cắm thêm an toàn riêng của bạn hoặc thực hiện bất kỳ thiết lập nào. Theo mặc định, DB2 được cấu hình để sử dụng các trình cắm thêm an toàn mặc định kèm theo. Các trình cắm thêm an toàn mặc định này gọi các API an toàn của hệ điều hành, do đó, hoạt động an toàn mặc định giống hệt như trong các phiên bản DB2 trước đó.

Hình 3 cho thấy các trình cắm thêm mặc định đi kèm với DB2, và vị trí của chúng trên hệ thống Windows.

Hình 3. Cấu trúc thư mục với các thư viện của trình cắm thêm an toàn mặc định trên Windows
Cấu trúc thư mục với các thư viện của trình cắm thêm an toàn mặc định trên Windows

Ô bên phải trong mỗi cửa sổ của Hình 3 cho thấy các trình cắm thêm mặc định khác nhau. Bảng 1 dưới đây mô tả từng trình cắm thêm này.

Bảng 1. Các trình cắm thêm mặc định IBM DB2
Tên trình cắm thêmMô tả
1IBMOSauthclientĐây là trình cắm thêm xác thực dựa vào hệ điều hành phía máy khách.
2IBMOSauthserverĐây là trình cắm thêm xác thực dựa vào hệ điều hành phía máy chủ.
3IBMOSgroupĐây là trình cắm thêm thành viên nhóm dựa vào hệ điều hành.
4IBMkrb5Đây là trình cắm thêm an toàn Kerberos (có cả hai mã phía máy khách và mã phía máy chủ trong cùng một thư viện).

Bất kỳ trình cắm thêm nào trong Hình 3 có hậu tố "TwoPart" đều thực hiện cùng một phương thức xác thực như một trình cắm thêm không có hậu tố đó, nhưng nó đã thêm khả năng xử lý các authID hai phần. Các authID hai phần cho phép sử dụng các vùng tên [c1], vì vậy, nhiều tài khoản có thể sử dụng cùng authID miễn là chúng đang ở trong các vùng tên khác nhau. Ví dụ, cả hai DOMAIN1\SUSHMA và DOMAIN2\SUSHMA là các authID hợp lệ cho một trình cắm thêm xử lý các authID hai phần. Trong các ví dụ này, DOMAIN1 và DOMAIN2 là các vùng tên (theo Windows, gọi chung là các miền của Windows).

Nếu bạn không muốn sử dụng các trình cắm thêm mặc định, bạn có thể hoặc viết các trình cắm thêm an toàn riêng của bạn, hoặc mua chúng từ một nhà cung cấp thứ ba. Bất kể bạn chọn cách nào, bạn cần tuân thủ các quy tắc cơ bản do DB2 đưa ra để viết trình các cắm thêm an toàn. Điều này được thảo luận chi tiết hơn trong phần sau.


Các trình cắm thêm ID/mật khẩu người dùng so với các trình cắm thêm GSS-API

Trước khi bạn bắt đầu phát triển các trình cắm thêm riêng của mình, bạn cần hiểu rằng khi sử dụng trình cắm thêm có thể thực hiện việc xác thực theo hai cách:

  • Sử dụng một trình cắm thêm dựa vào ID/mật khẩu người dùng— Điều này ngụ ý rằng một ID và mật khẩu người dùng được chuyển cho các trình cắm thêm để kiểm tra. Đây là một cách thực hiện đơn giản dễ hiểu hơn; tuy nhiên, chỉ có thể gửi ID và mật khẩu người dùng đến máy chủ, và chỉ có một trình cắm thêm máy chủ hoặc trình cắm thêm máy khách có thể được hỗ trợ.
  • Sử dụng một trình cắm thêm dựa vào GSS-API— Điều này có nghĩa là việc xác thực sử dụng Phiên bản 2 của tiêu chuẩn GSS-API (Generic Security Service Application Programming Interface – Giao diện lập trình ứng dụng của dịch vụ an toàn chung), như được ghi lại trong RFC 2743 và 2744. GSS-API là một API tổng quát để thực hiện xác thực máy khách-máy chủ. GSS-API là một tiêu chuẩn để giải quyết vấn đề về sự tồn tại của các dịch vụ an toàn tương tự nhưng không tương thích đang sử dụng hiện nay. Ưu điểm chính của việc sử dụng GSS-API là nhờ việc viết API tổng quát này, nên công cụ của bạn có thể cùng làm việc tin cậy với các hệ thống an toàn khác nhau. Kerberos và PKI đã hỗ trợ GSS-API, và trên thực tế, việc xác thực Kerberos trong DB2 được thực hiện bằng cách sử dụng mô hình GSS-API.
    Một ưu điểm khác của việc sử dụng kiểu xác thực của trình cắm thêm này là có thể truyền bất kỳ dữ liệu xác thực nào (bao gồm cả dữ liệu nhị phân) giữa máy khách và máy chủ. Việc xác thực được thực hiện ở cả máy khách và máy chủ; do đó bạn nên cấu hình máy khách và máy chủ để sử dụng trình cắm thêm GSS-API giống nhau. Để cấu hình máy khách, chỉ cần sao chép trình cắm thêm GSS-API vào thư mục trình cắm thêm của máy khách. Tại máy chủ, một danh sách các trình cắm thêm GSS-API theo thứ tự được chỉ rõ trong tham số cấu hình trình quản lý cơ sở dữ liệu SRVCON_GSSPLUGIN_LIST. Nếu một máy khách đã sao chép nhiều hơn một trình cắm thêm GSS-API, máy chủ sẽ xác định sử dụng một bản sao nào, dựa vào danh sách thứ tự đó. Hình 4 minh họa khái niệm này.
Hình 4. Chỉ rõ các trình cắm thêm GSS-API tại các hệ thống máy khách và máy chủ.
Chỉ rõ các trình cắm thêm GSS-API tại các hệ thống máy khách và máy chủ

Hình này cho thấy ba máy khách DB2 đang sử dụng các trình cắm thêm GSS-API khác nhau, và một máy chủ DB2 có một danh sách các các trình cắm thêm GSS-API mà nó hỗ trợ. Khi máy khách #1 kết nối đến máy chủ, máy chủ sẽ duyệt qua danh sách các trình cắm thêm của mình theo thứ tự từ trái sang phải cho đến khi nó tìm thấy một trình cắm thêm phù hợp với trình cắm thêm của máy khách, và sau đó sử dụng trình cắm thêm này. Vì vậy, đối với máy khách này máy chủ thấy rằng trình cắm thêm đầu tiên được nó hỗ trợ là ABC, và phù hợp với ABC.dll, do đó, máy chủ chọn trình cắm thêm này. Không cần tiếp tục duyệt danh sách xuống nữa, mặc dù trình cắm thêm DEF cũng được cả hai máy khách và máy chủ hỗ trợ. Đối với máy khách #3, một lỗi (mã lý do SQLCODE -30082 số 15) được trả về, do không có một trình cắm thêm GSS-API nào phù hợp giữa máy khách và máy chủ.

Một cá thể máy chủ DB2 sẽ chỉ có thể hỗ trợ một mô đun xác thực ID/mật khẩu người dùng, nhưng sẽ có thể hỗ trợ một danh sách các trình cắm thêm GSS-API. Tuy nhiên, chỉ có một trình cắm thêm trong danh sách có thể là một trình cắm thêm Kerberos. Các ứng dụng khách DB2 sẽ chỉ có thể hỗ trợ một mô đun ID/mật khẩu người dùng, nhưng sẽ thỏa thuận với máy chủ về một trình cắm thêm GSS-API cụ thể.

Các trình cắm thêm GSS-API phức tạp hơn, và cần có một sự hiểu biết rõ về khái niệm GSS-API quan trọng.


Các tính năng mới có sẵn trong các trình cắm thêm an toàn tùy chỉnh

Với kết quả của mô hình trình cắm thêm an toàn mới được giới thiệu trong Phiên bản 8.2, bạn có thể:

  • Thực hiện ánh xạ lại userID, mật khẩu, và vùng tên trên máy khách. Điều này chỉ có thể áp dụng cho các trình cắm thêm dựa trên ID/mật khẩu người dùng. Tính năng này có công dụng đặc biệt trong một hệ thống ba tầng ở đó máy chủ Web và máy khách DB2 tạo nên tầng giữa. Một ví dụ về ánh xạ lại userID, mật khẩu, và vùng tên được minh họa trong ví dụ 1 của phần Các ví dụ, ở đây người dùng sugsc1ch và mật khẩu của anh ta được trình cắm thêm máy khách ánh xạ tới người dùng Newton và mật khẩu của anh ta trước khi gửi yêu cầu kết nối đến máy chủ.
  • Thực hiện ánh xạ lại authID trên máy chủ. Tính năng này cho phép các ID người dùng khác nhau chia sẻ cùng ID ủy quyền trên máy chủ cơ sở dữ liệu một khi được xác thực. Tính năng này được biểu thị trong các thử nghiệm với ví dụ 1 của phần Các ví dụ. Ví dụ, tính năng này rất có ích, khi có các nhân viên trong một phòng có các ca làm việc luân phiên và thực hiện các nhiệm vụ tương tự hàng ngày đòi hỏi phải có cùng các đặc quyền. Nhờ sử dụng tính năng này, bạn có thể xác thực tất cả nhân viên này một cách độc lập và sử dụng các đặc quyền liên quan với authID chung để thực hiện các nhiệm vụ của họ. Để tìm ra nhân viên nào thực hiện nhiệm vụ nào và khi nào, DB2 cho phép trình cắm thêm phía máy chủ trả về tên thật, rồi kiểm định sau. Để biết thêm thông tin, hãy tham khảo tài liệu API db2secGetAuthid.
  • Sử dụng các vùng tên người dùng (ví dụ, DOMAIN\user). Điều này đã được thảo luận ở trên trong phần Các trình cắm thêm an toàn mặc định.
  • Từ chối các kết nối dựa trên thông tin truyền thông. Có thể sử dụng tính năng này khi bạn muốn cho phép chỉ một vài địa chỉ IP được đăng nhập vào cơ sở dữ liệu tại một thời điểm cụ thể. Ví dụ 2 trong phần Các ví dụ minh họa cách bạn có thể thực hiện điều này.

Các bước để tạo một trình cắm thêm an toàn DB2

Có sáu bước để tạo một trình cắm thêm an toàn DB2. Mỗi bước được giải thích chi tiết hơn trong các phần sau:

  1. Bao gồm các tệp tiêu đề của trình cắm thêm an toàn trong trình cắm thêm của bạn:
    • sqllib/include/db2secPlugin.h
    • sqllib/include/gssapiDB2.h
      Lưu ý: Bạn chỉ cần gssapiDB2.h nếu bạn đang thực hiện trình cắm thêm an toàn dựa trên GSS-API.
  2. Viết các API cấu thành trình cắm thêm của bạn. Bạn cần viết một API khởi tạo thích hợp và tập các API còn lại cần thiết cho trình cắm thêm máy chủ, máy khách, hoặc nhóm của bạn.
  3. Điền vào cấu trúc con trỏ hàm trước khi trả về cho DB2.
    • Cho biết phiên bản API của trình cắm thêm được trình cắm thêm sử dụng.
    • Cho biết kiểu trình cắm thêm, ví dụ như ID/mật khẩu người dùng, GSS-API, Kerberos.
  4. Biên dịch mã nguồn trình cắm thêm và tạo một thư viện chia sẻ. Biên dịch là 32-bit hoặc 64-bit tương ứng với cá thể ứng dụng/máy chủ.
  5. Đặt thư viện này trong thư mục thích hợp.
  6. Chạy các trình cắm thêm bằng cách cập nhật các tham số của trình quản lý cơ sở dữ liệu.

Bước 1: Bao gồm các tệp tiêu đề của trình cắm thêm an toàn trong trong trình cắm thêm của bạn

db2secPlugin.h và gssapiDB2.h hai tệp tiêu đề cần thiết để thực hiện các trình cắm thêm an toàn tùy chỉnh. Tệp tiêu đề gssapiDB2.h chỉ cần thiết nếu bạn đang xây dựng một trình cắm thêm GSS-API. Hình 5 cho thấy vị trí của hai tệp tiêu đề cần thiết để thực hiện trình cắm thêm an toàn trên một hệ thống Windows.

Hình 5. Vị trí các tệp tiêu đề của trình cắm thêm trên một hệ thống Windows
Vị trí các tệp tiêu đề của trình cắm thêm trên một hệ thống Windows

Bước 2: Viết các API cấu thành trình cắm thêm của bạn

Tùy thuộc vào liệu bạn có đang làm việc trên một trình cắm thêm máy chủ, trình cắm thêm máy khách, hoặc trình cắm thêm nhóm hay không, bạn sẽ cần mã hóa các API tương ứng sau đây để khởi tạo trình cắm thêm:

  • db2secServerAuthPluginInit
  • db2secClientAuthPluginInit
  • db2secGroupPluginInit

Ví dụ, API db2secServerAuthPluginInit có thể được mã hóa theo cách sau:

Liệt kê 1. db2secServerAuthPluginInit
SQL_API_RC SQL_API_FN db2secServerAuthPluginInit(
   db2int32             version,
   void*                server_fns,
   db2secGetConDetails* getConDetails_fn,
   db2secLogMessage*    logMessage_fn,
   char**               errormsg,
   db2int32*            errormsglen)
{
   struct userid_password_server_auth_functions_1
      *fns = (struct userid_password_server_auth_functions_1*) server_fns;

   condetails_fn = getConDetails_fn;
   logMessage_Fn = logMessage_fn;

   fns->version    = DB2SEC_API_VERSION;
   fns->plugintype = DB2SEC_PLUGIN_TYPE_USERID_PASSWORD;
   fns->db2secDoesAuthIDExist      = &is_user;
   fns->db2secFreeErrormsg         = &free_error_message;
   fns->db2secFreeToken            = &free_token;
   fns->db2secGetAuthIDs           = &getauthids;
   fns->db2secServerAuthPluginTerm = &terminate_plugin;
   fns->db2secValidatePassword     = &validatePassword;

   /* Example on how to use logMessage_fn */
   /* Will log the init successful information into db2diag.log at DIAGLEVEL 3 */
   (logMessage_Fn)(DB2SEC_LOG_WARNING,
                   "db2secServerAuthPluginInit successful",
                   strlen("db2secServerAuthPluginInit successful"));

   return DB2SEC_PLUGIN_OK;
}

DB2 gọi API db2secServerAuthPluginInit để khởi tạo thư viện trình cắm thêm máy chủ sau khi nó được DB2 tải. Đoạn mã trên được lấy từ tệp txtserver.c, có trong tệp ZIP đính kèm ở cuối bài này.

Ngoài các hàm khởi tạo, có một số các API của trình cắm thêm mà bạn cần để thực hiện với các trình cắm thêm máy chủ, máy khách, và nhóm. Ngoài ra, còn có các API cụ thể cho việc xác thực ID/mật khẩu người dùng và cho việc xác thực GSS-API. Hình 6, 7, và 8 mô tả những gì các hàm này thực hiện.

Lưu ý: Các hướng dẫn sử dụng DB2 có một phần mô tả chi tiết cách phát triển các trình cắm thêm an toàn, cũng như các giải thích về các API của trình cắm thêm an toàn. Các chi tiết đó nằm ngoài phạm vi của bài này. Phần này chỉ trình bày một tổng quan về API của trình cắm thêm đơn giản.

Hình 6. Trình cắm thêm tra tìm thành viên nhóm
Trình cắm thêm tra tìm thành viên nhóm
Hình 7. Trình cắm thêm máy khách
Trình cắm thêm máy khách
Hình 8. Trình cắm thêm máy chủ
Trình cắm thêm máy chú

Bước 3: Điền cấu trúc con trỏ hàm trước khi trả về cho DB2

Con trỏ hàm trả về các con trỏ tới tất cả các API cần thiết cho thư viện trình cắm thêm cụ thể mà bạn đã thực hiện. Ví dụ, trong trường hợp các trình cắm thêm nhóm, nó chứa các con trỏ cho các công cụ của các API db2secDoesGroupExist, db2secFreeErrormsg, db2secFreeGroupListMemory, db2secGetGroupsForUser, và db2secPluginTerm của bạn.

Tệp txtgroup.c, có trong tệp ZIP đính kèm ở cuối bài này, cung cấp một ví dụ về cách bạn có thể điền con trỏ các hàm cho thư viện trình cắm thêm nhóm. Dưới đây là một đoạn trích của mã này.

fns->version = DB2SEC_API_VERSION;
fns->db2secDoesGroupExist      = &is_group;
fns->db2secFreeErrormsg        = &free_error_message;
fns->db2secFreeGroupListMemory = &free_group_list;
fns->db2secGetGroupsForUser    = &get_groups;
fns->db2secPluginTerm          = &terminate_plugin;

Bước 4: Biên dịch mã nguồn của trình cắm thêm và tạo một thư viện chia sẻ

Một khi bạn đã hoàn tất việc mã hóa trình cắm thêm an toàn của mình, hãy biên dịch nó thành hoặc một thư viện 32-bit hoặc một thư viện 64-bit tương ứng với cá thể DB2 của bạn. Thư viện này phải có tên giống như tên của trình cắm thêm. Các thư viện phải là các thư viện chia sẻ có phần mở rộng đặc trưng phù hợp. Ví dụ, nếu tên của trình cắm thêm của bạn là myPlugin, thì cần các phần mở rộng sau:

  • myPlugin.dll (Windows)
  • myPlugin.a (AIX)
  • myPlugin.so (Linux, AIX, Sun Solaris, HP-UX
  • myPlugin.sl (HP-UX)

Các thư viện phải là an toàn luồng (đăng ký lại) và phải sử dụng liên kết-C (ít nhất là với các hàm khởi tạo).

Bước 5: Đặt thư viện vào thư mục thích hợp

Bạn phải đặt các thư viện trình cắm thêm an toàn vào các thư mục cụ thể:

  1. Windows:
    • sqllib\security\plugin\<instance name>\client
    • sqllib\security\plugin\<instance name>\server
    • sqllib\security\plugin\<instance name>\group

    Với các trình cắm thêm mặc định do IBM cung cấp:

    • sqllib\security\plugin\IBM\client
    • sqllib\security\plugin\IBM\server
    • sqllib\security\plugin\IBM\group
  2. 32-bit Linux và UNIX:
    • sqllib/security32/plugin/client
    • sqllib/security32/plugin/server
    • sqllib/security32/plugin/group

    Với các trình cắm thêm mặc định do IBM cung cấp:

    • sqllib/security32/plugin/IBM/client
    • sqllib/security32/plugin/IBM/server
    • sqllib/security32/plugin/IBM/group

Trong Linux và UNIX, các thư mục tương tự cho các thư viện 64-bit được sử dụng như nói trên, trừ tên thư mục con security64 được sử dụng thay cho security32. Trên các cá thể 64-bit của Windows, các trình cắm thêm 32-bit và 64-bit sẽ nằm trong cùng thư mục, nhưng các trình cắm thêm 64-bit sẽ được thêm vào một hậu tố '64', ví dụ, myplugin64.dll.

Lưu ý: Thư mục con IBM (trong thư mục plugin) được dành riêng cho các trình cắm thêm mặc định do IBM cung cấp. Bất kỳ trình cắm thêm tùy chỉnh nào khác được đặt trong thư mục này sẽ bị bỏ qua.

Bước 6: Chạy các trình cắm thêm bằng cách cập nhật các tham số của trình quản lý cơ sở dữ liệu

Trước phiên bản 8.2, tham số cấu hình của trình quản lý cơ sở dữ liệu authentication đã nói rõ vị trí và cơ chế để thực hiện các việc kiểm tra CONNECT/ATTACH, tra tìm nhóm, và ủy quyền cục bộ. Với phiên bản 8.2, có sẵn nhiều tham số cấu hình hơn, cung cấp nhiều sự linh hoạt hơn trong việc lựa chọn các tùy chọn xác thực.

Bảng 2 cung cấp một danh sách các tham số cấu hình trình quản lý cơ sở dữ liệu áp dụng cho các trình cắm thêm, và giải thích về cách chúng áp dụng cho các trình cắm thêm an toàn.

Bảng 2. Mô tả các tham số cấu hình của trình quản lý cơ sở dữ liệu của trình cắm thêm an toàn
Tên tham sốMô tả
1Trình cắm thêm ID/mật khẩu người dùng của máy khách (CLNT_PW_PLUGIN) Nếu giá trị này được thiết lập tại máy khách, và tham số AUTHENTICATION tại máy chủ được thiết lập là CLIENT, tham số này cho biết trình cắm thêm ID/mật khẩu người dùng để dùng cho việc xác thực được thực hiện ở máy khách. Nếu giá trị này được thiết lập ở máy chủ, tham số này cho biết trình cắm thêm ID/mật khẩu người dùng để dùng cho việc kiểm tra uỷ quyền các hoạt động cá thể như db2start. Trình cắm thêm phía máy khách cũng được sử dụng trên máy chủ cơ sở dữ liệu trong lúc một kết nối cơ sở dữ liệu được ban hành cục bộ trên máy chủ cơ sở dữ liệu (kết nối cục bộ).
2Trình cắm thêm Kerberos máy khách (CLNT_KRB_PLUGIN) Giá trị của tham số này quy định tên của thư viện trình cắm thêm Kerberos được dùng để xác thực phía máy khách và ủy quyền cục bộ. Sử dụng trình cắm thêm này khi xác thực máy khách bằng cách sử dụng xác thực Kerberos hoặc KRB_SERVER_ENCRYPT. Giá trị mặc định trên Windows là IBMkrb5. Trên nền tảng khác, giá trị mặc định là NULL.
3Trình cắm thêm nhóm (GROUP_PLUGIN) Giá trị của tham số này xác định thư viện trình cắm thêm nhóm được sử dụng để tra tìm thành viên nhóm.
4Trình cắm thêm GSS-API với ủy quyền cục bộ (LOCAL_GSSPLUGIN) Giá trị của tham số này quy định tên của thư viện trình cắm thêm GSS-API được sử dụng để ủy quyền cục bộ mức cá thể khi giá trị của tham số cấu hình của trình quản lý cơ sở dữ liệu AUTHENTICATION được thiết lập là GSSPLUGIN hoặc GSS_SERVER_ENCRYPT.
GSSPLUGIN cho biết rằng máy chủ sẽ chỉ xác thực bằng cách sử dụng một trình cắm thêm dựa trên GSS-API mà máy chủ đã quen dùng.
GSSPLUGIN_SERVER_ENCRYPT cho biết máy chủ sẽ chấp nhận thêm các yêu cầu ID/mật khẩu người dùng được mã hóa; kiểu này được tạo sẵn chủ yếu cho tương thích hướng xuống.
5Chế độ trình cắm thêm máy chủ(SRV_PLUGIN_MODE)Tham số này quy định liệu có chạy trong chế độ có rào chắn hoặc chế độ không có rào chắn hay không. Giá trị mặc định — và giá trị được hỗ trợ duy nhất — là UNFENCED (không có rào chắn).
6Danh sách máy chủ của các trình cắm thêm GSS-API (SRVCON_GSSPLUGIN_LIST)Tham số này quy định một danh sách được phân cách bằng dấu phẩy của các thư viện trình cắm thêm GSS-API được máy chủ cơ sở dữ liệu hỗ trợ. Danh sách này có thể chứa một trình cắm thêm Kerberos duy nhất. Nếu tham số này để trống, và AUTHENTICATION được thiết lập là Kerberos hoặc KRB_SVR_ENCRYPT, thì trình cắm thêm Kerberos của DB2 mặc định (IBMkrb5) sẽ được sử dụng.
7Trình cắm thêm ID/mật khẩu người dùng máy chủ (SRVCON_PW_PLUGIN) Giá trị của tham số này xác định thư viện trình cắm thêm ID/mật khẩu người dùng được sử dụng để xác thực phía máy chủ.
8Xác thực kết nối máy chủ (SRVCON_AUTH)Chỉ sử dụng giá trị của tham số này cho các kết nối. Nó sẽ ghi đè lên các phương thức xác thực được quy định trong AUTHENTICATION. Các hoạt động cá thể cục bộ vẫn sử dụng phương thức được quy định trong AUTHENTICATION. Giá trị mặc định là NOT_SPECIFIED (Không được quy định).
9Xác thực trình quản lý cơ sở dữ liệu (AUTHENTICATION)Giá trị của tham số này quy định cách thức và nơi sẽ diễn ra xác thực của người dùng để kiểm tra ủy quyền cá thể cục bộ. Giá trị mặc định là SERVER.

Bảng 3 cho thấy các bước bạn sẽ nhận được để chạy các trình cắm thêm xác thực ID/mật khẩu người dùng bằng cách sử dụng các tham số cấu hình được liệt kê ở trên.

Bảng 3. Các bước để chạy các trình cắm thêm xác thực ID/mật khẩu người dùng
Các bước trên máy kháchCác bước trên máy chủ
1Cập nhật CLNT_PW_PLUGIN với tên trình cắm thêm máy khách.
Nếu CLNT_PW_PLUGIN để trống, bước này sẽ mặc định là IBMOSauthclient, một trình cắm thêm do IBM cung cấp.
Cập nhật SRVCON_PW_PLUGIN với tên trình cắm thêm máy chủ.
2
Đặt SRVCON_AUTH tới một kiểu xác thực hệ thống (CLIENT, SERVER, SERVER_ENCRYPT, DATA_ENCRYPT, hoặc DATA_ENCRYPT_CMP), hoặc thiết lập SRVCON_AUTH là NOT_SPECIFIED và thiết lập AUTHENTICATION tới một kiểu xác thực hệ thống.
Nếu SRVCON_PW_PLUGIN để trống, bước này sẽ mặc định là IBMOSauthserver, trình cắm thêm do IBM cung cấp.

Bảng 4 cho thấy các bước mà bạn sẽ nhận được để chạy các trình cắm thêm tra tìm thành viên nhóm bằng cách sử dụng các tham số cấu hình được liệt kê ở trên.

Bảng 4. Các bước để chạy các trình cắm thêm tra tìm thành viên nhóm
Các bước trên máy kháchCác bước trên máy chủ
1Cập nhật GROUP_PLUGIN với tên của trình cắm thêm nhóm.
Nếu GROUP_PLUGIN để trống, bước này sẽ mặc định là IBMOSgroups, trình cắm thêm do IBM cung cấp.
Cập nhật GROUP_PLUGIN với tên của trình cắm thêm nhóm.
Nếu GROUP_PLUGIN để trống, bước này sẽ mặc định là IBMOSgroups, trình cắm thêm do IBM cung cấp.

Bảng 5 cho thấy các bước bạn sẽ nhận được để chạy các trình cắm thêm xác thực GSS-API bằng cách sử dụng các tham số cấu hình được liệt kê ở trên.

Bảng 5. Các bước để chạy các trình cắm thêm xác thực GSS-API
Các bước trên máy kháchCác bước trên máy chủ
1Đặt thư viện trình cắm thêm trong thư mục trình cắm thêm máy khách.Đặt thư viện trình cắm thêm trong thư mục trình cắm thêm máy chủ.
2Tùy chọn: Tạo danh mục một cơ sở dữ liệu cho biết rằng máy khách sẽ chỉ sử dụng một trình cắm thêm GSS-API để xác thực. Ví dụ: db2 catalog db testdb at node testnode authentication gssplugin
Nhiều trình cắm thêm có thể cùng tồn tại trên máy khách. Trong trường hợp này, máy chủ sẽ nói rõ sử dụng một trình cắm thêm nào.
Cập nhật SRVCON_GSSPLUGIN_LIST với một danh sách theo thứ tự các tên của trình cắm thêm có hỗ trợ. Để chạy trình cắm thêm GSS-API, bạn có thể hoặc:
  • Đặt SRVCON_AUTH là GSSPLUGIN, hoặc
  • Đặt SRVCON_AUTH là NOT_SPECIFIED, và đặt AUTHENTICATION là GSSPLUGIN.
Để chạy ủy quyền cục bộ:
  1. Đặt thư viện trình cắm thêm máy khách trong thư mục trình cắm thêm máy khách.
  2. Cập nhật LOCAL_GSSPLUGIN với tên của trình cắm thêm này.

Bảng 6 cho thấy các bước bạn sẽ nhận được để chạy các trình cắm thêm xác thực Kerberos bằng cách sử dụng các tham số cấu hình liệt kê ở trên.

Bảng 6. Các bước để chạy các trình cắm thêm Kerberos
Các bước trên máy kháchCác bước trên máy chủ
1Đặt thư viện trình cắm thêm trong thư mục trình cắm thêm máy khách.Đặt thư viện trình cắm thêm trong thư mục trình cắm thêm máy chủ.
2Cập nhật CLNT_KRB_PLUGIN với tên của trình cắm thêm Kerberos.
  • Nếu CLNT_KRB_PLUGIN để trống, thì DB2 giả định rằng máy khách không có khả năng sử dụng Kerberos.
  • Trình cắm thêm Kerberos mặc định do DB2 cung cấp có tên là IBMkrb5.
  • Đối với các nền tảng hỗ trợ Kerberos, thư viện IBMkrb5 đã có mặt trong thư mục trình cắm thêm của máy khách rồi.
Cập nhật SRVCON_GSSPLUGIN_LIST với tên của trình cắm thêm Kerberos máy chủ.
3Tùy chọn: Tạo danh mục một cơ sở dữ liệu cho biết máy khách sẽ sử dụng trình cắm thêm Kerberos để xác thực. Ví dụ: db2 catalog db testdb at node testnode authentication kerberos target principal service/host@REALMĐặt SRVCON_AUTH là KERBEROS hoặc KRB_SERVER_ENCRYPT, hoặc đặt SRVCON_AUTH là NOT_SPECIFIED và đặt AUTHENTICATION là KERBEROS hoặc KRB_SERVER_ENCRYPT.

Các ví dụ trình diễn cách thực hiện các trình cắm thêm an toàn đơn giản

Tệp ZIP đi kèm theo bài này gồm có mã nguồn của các trình cắm thêm được sử dụng trong phần này và một tệp README có nhiều thông tin hơn về chúng.

Ví dụ 1: Thực hiện một trình cắm thêm an toàn ID/mật khẩu người dùng đơn giản

Các tệp cần thiết: txtserver.c, txtclient.c, txtcommon.c, và txtplugin_makefile.

Bạn sẽ cần thực hiện cả hai trình cắm thêm phía máy chủ và phía khách như sau.

  1. Mở tệp txtcommon.c và sửa đổi dòng sau đây để chứa ID và mật khẩu người dùng của bạn. Giữ lại authID là REMAP. Thay đổi myuserid theo ID người dùng của bạn và er9etw0 theo mật khẩu của bạn.
    { 0, 0, "REMAP", "REMAP", "myuserid", "er9etw0", "build" }
  2. Tạo một thư mục con dưới thư mục C:\...\sqllib\security\plugins, đặt tên thư mục mới sau tên cá thể của bạn.
  3. Tạo hai thư mục con có tên là máy khách và máy chủ trong thư mục con mà bạn đã tạo ở bước trước.
  4. Ban hành các lệnh sau từ một Cửa sổ lệnh DB2 (DB2 Command Window) để tạo noplatos và cơ sở dữ liệu mẫu:
    • db2start
    • db2 create db noplatos
    • db2sampl
    • db2stop
  5. Đổi tên tệp txtplugin_makefile là makefile.
  6. Biên dịch tệp txtserver.c bằng cách ban hành lệnh sau:
    nmake /f makefile txtserver
    Sao chép tệp txtserver.dll đã tạo vào thư mục C:\...\sqllib\security\plugins\<instance_name>\server để DB2 có thể tìm thấy nó.
  7. Cập nhật các tham số cấu hình của trình quản lý cơ sở dữ liệu bằng cách ban hành lệnh sau từ Cửa sổ lệnh DB2:
    db2 update dbm cfg using srvcon_auth server srvcon_pw_plugin txtserver
  8. Ban hành các lệnh sau từ Cửa sổ lệnh DB2 để đảm bảo rằng các thay đổi cấu hình của bạn có hiệu lực:
    • db2 terminate
    • db2stop
    • db2start
  9. Bây giờ bạn đã sẵn sàng thử nghiệm trình cắm thêm xác thực ID/mật khẩu người dùng phía máy chủ của bạn. Hãy ban hành các lệnh/các câu lệnh sau từ Cửa sổ lệnh DB2.
    1. db2 connect to sample user <your user ID> using <your password>
      Câu lệnh này sẽ trả về ánh xạ authID cho ID người dùng của bạn. API db2secGetAuthIDs lấy ra authID từ bảng trong tệp txtcommon.c. Bạn sẽ nhận được kết quả đầu ra thể hiện trong Hình 9:
Hình 9. Thử nghiệm API db2secGetAuthIDs
Thử nghiệm API db2secGetAuthIDs
  1. db2 connect to noplatos user plato using er9etw0
    Câu lệnh này sẽ không chạy với thông báo mã lý do sqlcode 30082 số 25. ID người dùng là plato không thể truy cập cơ sở dữ liệu noplatos nếu gọi trình cắm thêm phía máy chủ để xác thực. Điều này xảy ra là do mã trong hàm validatePassword trong tệp txtserver.c, hạn chế không cho người dùng plato truy cập cơ sở dữ liệu noplatos.
  2. db2 connect to sample user plato using er9etw0
    Câu lệnh này sẽ chạy thành công. ID người dùng plato có thể truy cập cơ sở dữ liệu khác với noplatos khi gọi trình cắm thêm phía máy chủ để xác thực. Hình 10 cho thấy kết quả đầu ra cho trường hợp này.
Hình 10. Thử nghiệm cho thấy truy cập bị hạn chế của plato vào noplatos
Thử nghiệm cho thấy truy cập bị hạn chế của plato vào noplatos
  1. Biên dịch tệp txtclient.c bằng cách ban hành lệnh sau:
    nmake /f makefile txtclient
    Sao chép tệp txtclient.dll đã tạo tới thư mục máy khách C:\...\sqllib\security\plugins\<instance_name>\client để DB2 có thể tìm thấy nó.
  2. Cập nhật các tham số cấu hình của trình quản lý cơ sở dữ liệu bằng cách đưa ra lệnh sau từ Cửa sổ lệnh DB2:
    db2 update dbm cfg using srvcon_auth client clnt_pw_plugin txtclient
  3. Ban hành các lệnh sau từ Cửa sổ lệnh DB2 để đảm bảo rằng các thay đổi cấu hình của bạn có hiệu lực:
    • db2 terminate
    • db2stop
    • db2start
  4. Bây giờ bạn đã sẵn sàng thử nghiệm trình cắm thêm xác thực ID/mật khẩu người dùng phía máy khách của bạn. Hãy ban hành các lệnh sau từ Cửa sổ lệnh DB2.
    1. db2 connect to sample user sugsc1ch using cdsecpwd

      API db2secRemapUserid được gọi, và người dùng là sugsc1ch có mật khẩu cdsecpwd được ánh xạ tới người dùng newton có mật khẩu er9etw0 và sau đó sử dụng authID cho newton để nối với cơ sở dữ liệu. Chức năng này được thực hiện trong hàm remap_userid của tệp txtclient.c như sau:

      /* remap the userid sugsc1ch to newton */
      else if (!strncmp("sugsc1ch", userid, 8) &&
              !strncmp("cdsecpwd", password, 8))
      {
           /* this is for testing purposes only: userid sugsc1ch/cdsecpwd
            normally has no privileges, but I am going to remap it to
            newton/er9etw0 so that it will be allowed to connect if
            server plugin is txtserver, and fail if the os plugin is used */
      
            strcpy(userid, "newton");
            strcpy(password, "er9etw0");
            *useridlen = strlen(userid);
            *passwordlen = strlen(password);
      }

      Câu lệnh này sẽ chạy thành công và kết quả đầu ra sẽ giống trong Hình 11.

Hình 11. Thử nghiệm API db2secRemapUserid
Thử nghiệm API db2secRemapUserid
  1. db2 connect to noplatos user plato using er9etw0
    Câu lệnh này sẽ chạy thành công, do thực hiện hạn chế người dùng 'plato' kết nối tới noplatos trong trình cắm thêm phía máy chủ và chứ không phải trong trình cắm thêm phía máy khác.
  2. db2 connect to sample
    Câu lệnh này sẽ chạy thành công. Nó gọi API db2secGetDefaultLoginContext để lấy được authID của người dùng đang yêu cầu kết nối, và sử dụng nó để nối với cơ sở dữ liệu mẫu.

Ví dụ 2: Thực hiện một trình cắm thêm an toàn nhóm đơn giản

Các tệp cần thiết: txtgroup.c, txtserver,c, txtclient.c, txtcommon.c, và txtplugin_makefile.

Ví dụ này được xây dựng dựa trên ví dụ 1, do đó thực hiện các bước này trong ví dụ 1 trước khi tiến hành các bước sau.

  1. Tạo một thư mục con gọi là "nhóm" dưới thư mục con "DB2" đã tạo ra trong bước 2 của ví dụ 1.
  2. Biên dịch tệp txtgroup.c bằng cách ban hành lệnh sau:
    nmake /f makefile txtgroup
    Sao chép txtgroup.dll đã tạo vào thư mục C:\...\sqllib\security\plugins\<instance_name>\group để DB2 có thể tìm thấy nó.
  3. Cập nhật các tham số cấu hình của trình quản lý cơ sở dữ liệu bằng cách ban hành các lệnh sau từ Cửa sổ lệnh DB2:
    • db2 update dbm cfg using srvcon_auth server
    • db2 update dbm cfg using srvcon_pw_plugin txtserve
    • db2 update dbm cfg using sysadm_group build
    • db2 update dbm cfg using group_plugin txtgroup
  4. Ban hành các lệnh sau từ Cửa sổ lệnh DB2 để đảm bảo rằng những thay đổi cấu hình của bạn có hiệu lực:
    • db2 terminate
    • db2stop
    • db2start
  5. Bây giờ bạn đã sẵn sàng để thử nghiệm trình cắm thêm nhóm của bạn. Ban hành các lệnh/các câu lệnh sau từ Cửa sổ lệnh DB2. (Lưu ý: người dùng newton thuộc nhóm build là sysadm, và user2 thuộc về nhóm doody và một số nhóm khác)
    • db2 connect to sample user newton using er9etw0
      db2 "create table t1 (x int)"
      db2 terminate

      Hình 12 cho thấy kết quả của bước này:
Hình 12. Thử nghiệm thành viên nhóm và các ủy quyền của newton
Thử nghiệm thành viên nhóm và các ủy quyền của newton
  • db2 connect to sample user user2 using er9etw0
    db2 "select * from newton.t1"
    db2 terminate

    Hình 13 cho thấy kết quả của bước này:
Hình 13. Thử nghiệm các ủy quyền của user2
Thử nghiệm các ủy quyền của user2
  • db2 connect to sample user newton using er9etw0
    db2 grant select on t1 to group doody
    db2 terminate

    Hình 14 cho thấy kết quả của bước này:
Hình 14. Thử nghiệm các ủy quyền của newton để cấp các đặc quyền
Thử nghiệm các ủy quyền của newton để cấp các đặc quyền
  • db2 connect to sample user user2 using er9etw0
    db2 "select * from newton.t1"
    db2 terminate

    Hình 15 cho thấy kết quả của bước này:
Hình 15. Thử nghiệm các đặc quyền mới được cấp của user2
Thử nghiệm các đặc quyền mới được cấp của user2

Các bước để thử nghiệm khả năng hạn chế kết nối của trình cắm thêm

Bước này sẽ thử nghiệm tất cả ba trình cắm thêm (máy chủ, máy khách, và tra tìm thành viên nhóm).

Thêm các dòng sau vào các tệp C:\windows\system32\drivers\etc\services của bạn:
xregress 23542/tcp
xregress_int 23543/tcp

Ban hành các lệnh sau từ Cửa sổ lệnh DB2 như được minh họa trong Hình 16:
db2 terminate
db2stop
db2 update dbm cfg using clnt_pw_plugin txtclient srvcon_pw_plugin txtserver group_plugin txtgroup sysadm_group build
db2set DB2COMM=TCPIP
db2 update dbm cfg using svcename xregress
db2 catalog tcpip node thisnode remote <your machine name> server xregress
db2 catalog db sample as loopback at node thisnode
db2 terminate
db2start

Hình 16. Thiết lập khả năng hạn chế kết nối
Thiết lập khả năng hạn chế kết nối

Các bước trên cho phép bạn gọi lại tới DB2 để lấy được địa chỉ IP của máy khách. Sau đó, bạn có thể thêm logic cần thiết của bạn và chặn bất kỳ kết nối nào không phù hợp với mẫu được phép.

Bây giờ nếu bạn ban hành lệnh db2 connect to loopbackdb user beauvoir using er9etw0, (db2 kết nối tới người dùng loopbackdb là beauvoir bằng cách sử dụng er9etw0), bạn sẽ nhận được kết quả được minh họa trong Hình 17.

Hình 17. Thử nghiệm khả năng hạn chế kết nối
Thử nghiệm khả năng hạn chế kết nối

Kịch bản ở trên gọi hàm validatePassword (tương ứng với API db2secValidatePassword) trong tệp txtserver.c. Việc thực hiện hàm này nói rõ nếu ID người dùng là beauvoir cố gắng để kết nối từ một máy khách ở xa có một địa chỉ IP giống như địa chỉ IP của máy chủ cơ sở dữ liệu, thì chặn nó lại. Trong một kịch bản thực tế, bạn sẽ mã hóa hàm validatePassword sao cho bạn có một danh sách các địa chỉ IP được phép hoặc các địa chỉ IP không được phép, và kiểm tra lại danh sách đó trước khi chặn không cho một người dùng cụ thể truy cập vào cơ sở dữ liệu.

Ví dụ 3: Thực hiện một trình cắm thêm dựa vào Active Directory (Thư mục tích cực)

Các tệp cần thiết: ldap.c, ldap_makefile.

Active Directory là công cụ của một máy chủ LDAP của Microsoft và có mặt trên tất cả các trình điều khiển miền. Nó chứa thông tin tài khoản miền, nhóm, và máy tính. Active Directory hỗ trợ bộ API v2 và v3 của LDAP. Ví dụ này sẽ sử dụng LDAP_VERSION3.

Ví dụ này giả định rằng bạn đã hiểu các khái niệm cơ bản của LDAP và biết cách thiết lập một thư mục tích cực. Hướng dẫn "Hướng dẫn khởi động nhanh để thiết lập Active Directory" của serverwatch.com (xem phần Tài nguyên) cung cấp một tài liệu tham khảo tốt.

Khi một ứng dụng sử dụng máy chủ LDAP để xác thực, nó thường sử dụng kết buộc để truyền thông với máy chủ, và không kết buộc từ máy chủ để đóng kết nối.

Thông thường, có 4 bước được một ứng dụng thực hiện trong quá trình xác thực bằng cách sử dụng thư mục hoạt động là:

  1. Mở một kết nối đến máy chủ LDAP.
  2. Xác thực dựa vào máy chủ LDAP.
  3. Thực hiện một số hoạt động, như lấy các kết quả tìm kiếm.
  4. Đóng kết nối.

Trình cắm thêm của ví dụ này sử dụng các hàm API sau:

  1. ldap_init — Khởi tạo một kết nối đến máy chủ LDAP.
  2. ldap_connect — Kết nối đến một máy chủ LDAP.
  3. ldap_bind_s — Kết buộc đồng bộ đến máy chủ LDAP.
  4. ldap_unbind_s — Đóng kết nối đến máy chủ LDAP.

Ví dụ này là một trình cắm thêm xác thực phía máy chủ để xác thực ID và mật khẩu người dùng dựa vào một máy chủ LDAP.

Ví dụ này giả định một địa chỉ IP là 199.43.208.178 và số cổng là 389 cho máy chủ LDAP. Thực hiện tất cả 4 bước trong db2secValidatePassword.

Các bước trong db2secValidatePassword:

  1. Gọi ldap_init bằng cách sử dụng cổng và địa chỉ IP mặc định của máy chủ LDAP.
  2. Gọi ldap_set_option để thiết lập phiên bản giao thức với LDAP_VERSION3.
  3. Kết nối đến máy chủ LDAP bằng cách sử dụng ldap_connect.
  4. Trước khi bạn có thể kết buộc tới máy chủ LDAP, bạn phải chuyển dịch từ biểu mẫu tên tài khoản của SAM (Microsoft Security Accounts Manager -Trình quản lý tài khoản an toàn của Microsoft) (tùy chọn với một vùng tên) sang định dạng tên phân biệt LDAP. Một ví dụ về tên phân biệt là "cn = Il-Sung Lee, o = Microsoft, cn = US". Nếu không cung cấp một vùng tên như là một phần của chuỗi ký tự ID người dùng khi kết nối, bạn sẽ cần gọi hàm API của Windows là LookupAccountNameA để xác định vị trí vùng tên ở đó định nghĩa ID người dùng này. Một khi có sẵn cả hai vùng tên và ID của người dùng, hãy gọi hàm Windows API là TranslateNameA để thực hiện chuyển dịch.
  5. Kết buộc với máy chủ LDAP. Sử dụng phương thức xác thực là LDAP_AUTH_SIMPLE. Nếu mật khẩu được cấp cho người dùng phù hợp với mật khẩu của máy chủ LDAP với tên phân biệt tương ứng, thì hàm kết buộc sẽ trả về LDAP_SUCCESS. Nếu không, hàm kết buộc có thể trả về một trong các mã trả về được liệt kê trên Mạng nhà phát triển của Microsoft (Microsoft Developer Network) (xem phần Tài nguyên).
  6. Đóng kết nối đến máy chủ LDAP bằng ldap_unbind.

Tất cả các cuộc gọi API trình cắm thêm an toàn cần thiết khác rất dễ thực hiện và tương tự như trình cắm thêm xác thực ID/mật khẩu người dùng đơn giản. Bài này sẽ không đi sâu vào các chi tiết đó.

Cũng lưu ý rằng DB2 cho phép kết nối cục bộ thành công mà không cần cung cấp một ID và mật khẩu người dùng. Việc này được gọi là kết nối ngầm định. Trong một kết nối ngầm định, DB2 sẽ cung cấp các thông tin chi tiết về người dùng đã đăng nhập hiện tại cho trình cắm thêm an toàn phía máy chủ. Để xác định người dùng hiện đang đăng nhập, DB2 gọi hàm API của trình cắm thêm xác thực phía máy khách db2secGetDefaultLoginContext. Trong ví dụ này, chúng ta sẽ mặc định theo trình cắm thêm phía máy khách do IBM cung cấp để thực hiện việc này.

Để chạy trình cắm thêm xử lý trường hợp này, bạn cần thực hiện thêm một bước nữa trước khi gọi ldap_init. Sử dụng hàm gọi lại "get client connection details" (lấy các thông tin chi tiết về kết nối máy khách), do DB2 cung cấp, để tìm hiểu xem máy khách có là cục bộ với máy tính này không. Các mã để làm điều này được thể hiện dưới đây.

rc = pConDetails( DB2SEC_API_VERSION, &conDetails);
if( rc == DB2SEC_PLUGIN_OK )
{
  if( ( conDetails.connect_info_bitmap & DB2SEC_CONNECTION_ISLOCAL ) 
  && ( conDetails.connect_info_bitmap &
  (DB2SEC_VALIDATING_ON_SERVER_SIDE ) && ( passwordlen == 0 ) )
  {
    goto exit;
  }
}

Để biên dịch và xây dựng thư viện trình cắm thêm này, bạn có thể sử dụng ldap_makefile được cung cấp trong phần tải về dưới đây. Đổi tên nó là makefile, và sao chép vào bldplugin.bat từ thư mục sqllib\samples\security\plugins. Ban hành lệnh make ldap, sẽ sử dụng chương trình make với bldplugin.bat để xây dựng thư viện này.

Thực hiện các bước sau để sử dụng trình cắm thêm xác thực ID/mật khẩu người dùng phía máy chủ dựa trên LDAP đơn giản này:

Để thiết lập trình cắm thêm phía máy chủ:

  1. Cài đặt thư viện trình cắm thêm LDAP ở đúng vị trí đã đề cập ở trên trong bài này.
  2. Cập nhật tham số srvcon_pw_plugin với tên của trình cắm thêm LDAP.
  3. Thiết lập hoặc tham số srvcon_auth hoặc tham số cấu hình của trình quản lý cơ sở dữ AUTHENTICATION cho máy chủ.

Để thiết lập trình cắm thêm phía máy khách:

  1. Đăng nhập vào miền đó.
  2. Cập nhật tham số cấu hình trình quản lý cơ sở dữ liệu clnt_pw_plugin là NULL, mặc định theo trình cắm thêm xác thực phía máy khách do IBM cung cấp.

Nếu bạn đang có kế hoạch thử nghiệm trình cắm thêm cục bộ trên máy chủ cơ sở dữ liệu, bạn cũng sẽ phải thực hiện thiết lập phía máy khách trên máy tính của máy chủ cơ sở dữ liệu. Lý do với nó là, với ủy quyền cục bộ, ví dụ này sử dụng trình cắm thêm máy khách trên máy chủ cơ sở dữ liệu. Vì vậy, bạn nên có một phiên bản máy khách với kiểu trình cắm thêm thích hợp, theo giá trị mà bạn đã quy định trong tham số cấu hình trình quản lý cơ sở dữ liệu AUTHENTICATION. Ví dụ, nếu bạn có một máy chủ cơ sở dữ liệu ở đó quy định việc xác thực là kerberos, bạn sẽ cần đảm bảo rằng clnt_krb_plugin được thiết lập hoặc là IBMkrb5 (trình cắm thêm Kerberos do IBM cung cấp) hoặc là tên của trình cắm thêm Kerberos của ban. Bạn cũng cần đảm bảo cài đặt trình cắm thêm này trong thư mục trình cắm thêm máy khách trên máy chủ cơ sở dữ liệu. Nếu không, các hoạt động mức cá thể như db2start sẽ không chạy.

Một khi bạn đã thiết lập trình cắm thêm trên cả máy khách và máy chủ cơ sở dữ liệu, hãy ban hành một câu lệnh kết nối để thử nghiệm trình cắm thêm này.

Ví dụ 4: Sử dụng trình cắm thêm Kerberos để giải thích thêm công cụ DB2 của tiêu chuẩn GSS-API và phần mở rộng cụ thể DB2

Kerberos là một giao thức xác thực mạng của bên thứ ba sử dụng một hệ thống các khóa bí mật có chia sẻ để xác thực an toàn người dùng trong một môi trường mạng không an toàn. Nó sử dụng một hệ thống ba tầng, ở đó trao đổi các vé được mã hóa (được cung cấp bởi một máy chủ riêng biệt gọi là Trung tâm phân phối khóa Kerberos, hoặc gọi tắt là KDC) giữa máy chủ và máy khách ứng dụng chứ không phải là các cặp ID mật khẩu người dùng bằng văn bản. Chỉ máy khách và máy chủ hiểu các vé dịch vụ mã hóa (các chứng nhận), do đó có sự rủi ro an toàn tối thiểu, ngay cả trong trường hợp vé đó bị thu chặn trên mạng.

Một đặc điểm quan trọng của Kerberos là nó cho phép một môi trường đăng nhập một lần do đó người dùng chỉ cần xác minh danh tính của mình với tài nguyên trong lĩnh vực Kerberos một lần. Với DB2, điều này có nghĩa rằng người dùng sẽ có thể kết nối đến một máy chủ DB2 mà không cần cung cấp một ID hoặc mật khẩu người dùng. Kết nối đăng nhập một lần là một tính năng thường được các khách hàng yêu cầu và hiện không có sẵn thông qua DB2 (thông thường xác thực máy khách không phải là một lý do xem xét vì nó thường không phải là một lựa chọn khả thi cho các khách hàng). Một sự khích lệ mạnh mẽ về sử dụng Kerberos là nó cung cấp một kho lưu trữ trung tâm cho các ID (hoặc những người ủy thác) của người dùng do đó tập trung và đơn giản hóa việc quản trị chính. Hơn nữa, Kerberos hỗ trợ xác thực lẫn nhau, cho phép máy khách xác nhận hợp lệ định danh của máy chủ.

Trong Phiên bản 8,2, với mô hình trình cắm thêm an toàn DB2 mới, sẽ cung cấp sự hỗ trợ của Kerberos như là một trình cắm thêm GSS-API. Sự hỗ trợ của Windows 2000 hiện có được bổ sung lại như là một trình cắm thêm GSS-API, và ba nền tảng bổ sung sẽ được hỗ trợ là: AIX 5.2, Solaris 8, và Red Hat Enterprise Linux Advanced Server 2.1 (Máy chủ cao cấp Linux cho doanh nghiệp Red Hat phiên bản 2.1).

Ý tưởng cơ bản về cách Kerberos làm việc được minh họa trong Hình 18.

Hình 18. Toàn cảnh xác thực Kerberos
Toàn cảnh xác thực Kerberos

Mục đích của phần này là sử dụng trình cắm thêm Kerberos để giải thích cách hy vọng một trình cắm thêm xác thực dựa vào GSS-API hoạt động. Với Kerberos, một chứng nhận được tham khảo theo vé Kerberos. Có các biểu mẫu chứng nhận khác, tùy thuộc vào việc thực hiện GSS-API cụ thể. Ví dụ, trong công cụ cơ sở hạ tầng khóa công khai (PKI), một chứng nhận là một chứng chỉ được Cơ quan cấp chứng chỉ (CA) hoặc Cơ quan đăng ký (RA) cấp.

Dòng chảy xác thực GSS-API cơ bản

Bảng 7 cung cấp một minh họa đã đơn giản hóa về các dòng chảy máy chủ - máy khách cơ bản tham gia vào quá trình xác thực GSS-API. Lưu ý rằng các mã thông báo là dữ liệu nhị phân không nhìn thấy, và chỉ cần cơ chế an toàn cơ bản có khả năng giải thích chúng.

Bảng 7. Các dòng chảy máy chủ-máy khách có liên quan trong quá trình xác thực GSS-API
Máy kháchMáy chủ
1. Lấy các chứng nhận ban đầu của máy khách (GSS-API không bao gồm).
1. Lấy các chứng nhận của máy chủ (gss_acquire_cred).
2. Lấy các chứng nhận từ máy chủ (gss_init_sec_context).-->3. Kiểm tra và chấp nhận các chứng nhận máy khách (gss_accept_sec_context). Trả về mã thông báo xác thực lẫn nhau nếu có yêu cầu.
4. Thiết lập ngữ cảnh, hoặc xác thực lẫn nhau (gss_init_sec_context).<--
5. Xóa ngữ cảnh và kết thúc công việc.
5. Xóa ngữ cảnh và kết thúc công việc.

DB2 và GSS-API -- Dòng chảy cơ bản

Bảng 8 cho thấy các bước có liên quan trong một dòng chảy máy chủ-máy khách khi DB2 được tham gia vào quá trình xác thực GSS-API. Máy chủ lấy tên chính của nó và xử lý chứng nhận lúc khởi tạo trình cắm thêm (db2secServerAuthPluginInit). Lưu ý rằng trên máy chủ này, các trình cắm thêm được nạp và khởi tạo như là một phần của hoạt động của trình quản lý cơ sở dữ liệu khởi động (db2start).

Bảng 8. Các dòng chảy máy chủ-máy khách khi DB2 được tham gia vào quá trình xác thực GSS-API
Máy kháchMáy chủ
1. Lấy các chứng nhận ban đầu của máy khách khi cần (db2secGenerateInitialCreds), nếu không, lấy ngữ cảnh đăng nhập mặc định (db2secGetDefaultLoginContext).
2 . Xử lý tên người ủy thác máy chủ (db2secProcessServerPrincipalName)
3. Lấy các chứng nhận từ máy chủ (gss_init_sec_context)


--> 4. Vấn đề ủy quyền cục bộ.
5. Lấy các authID cho người ủy thác bắt đầu ngữ cảnh (db2GetAuthIDs) và lấy thông tin thành viên nhóm cho người ủy thác bằng cách gọi trình cắm thêm của thành viên nhóm (db2secGetGroupsForUser).
6. Thực hiện xác thực lẫn nhau nếu cần (gss_init_sec_context) <--
7. Xóa các ngữ cảnh (gss_delete_sec_context) và kết thúc công việc bằng cách gọi gss_release_buffer, gss_release_name, và db2secFreeToken. Nếu ID và mật khẩu người dùng được quy định trực tiếp, cũng gọi db2secFreeInitInfo trong giai đoạn kết thúc công việc.
7. Xóa các ngữ cảnh (gss_delete_sec_context) và kết thúc công việc bằng cách gọi db2secFreeToken. Cũng gọi hàm API của trình cắm thêm thành viên nhóm là db2secFreeGroupList, để xóa sạch bộ nhớ đã phân bổ trong cuộc gọi để lấy thành viên nhóm.

Mã nguồn của trình cắm thêm Kerberos cho UNIX và Linux được cung cấp như một mẫu trong sqllib/samples/security/plugins/IBMkrb5.c.

Những hạn chế do DB2 áp đặt lên các trình cắm thêm GSS-API

GSS-API là một tiêu chuẩn được DB2 hỗ trợ. Tuy nhiên, DB2 áp đặt các hạn chế về cách thực hiện các hàm GSS-API. Những hạn chế này gồm:

  1. Giả định cơ chế an toàn mặc định, do đó không xem xét OID.
  2. Các dịch vụ GSS duy nhất được yêu cầu trong gss_init_sec_context () là xác thực và ủy thác lẫn nhau. DB2 sẽ yêu cầu một vé cho việc ủy thác, nhưng sẽ không bao giờ sử dụng vé đó để tạo một vé mới.
  3. Chỉ yêu cầu thời gian ngữ cảnh mặc định.
  4. Các mã thông báo ngữ cảnh từ gss_delete_sec_context () không được gửi từ máy khách đến máy chủ và ngược lại.
  5. Không hỗ trợ ẩn danh.
  6. Không hỗ trợ kết buộc kênh.
  7. Nếu các chứng nhận ban đầu hết hạn, DB2 sẽ không tự động làm mới chúng.
  8. GSS-API yêu cầu là ngay cả khi gss_init_sec_context () hoặc gss_accept_sec_context () không chạy, nó có thể trả về mã thông báo để gửi tới phương tiện ngang hàng. Trong trường hợp này, bạn phải gửi một mã thông báo. Tuy nhiên, do các giới hạn trong một khung công tác DRDA, bạn chỉ có thể quản lý thực hiện điều này nếu gss_init_sec_context () không chạy và tạo ra một mã thông báo về cuộc gọi đầu tiên.

Các hạn chế sử dụng với các trình cắm thêm an toàn

  1. Không chạy máy chủ quản trị với các trình cắm thêm. Vì vậy, bất kỳ hành động nào thông qua Trung tâm điều khiển (hoặc Trung tâm khác), xảy ra thông qua máy chủ quản trị (chứ không phải qua một kết nối cơ sở dữ liệu), sẽ nhắc cho một ID và mật khẩu người dùng sẽ được xác nhận hợp lệ dựa vào hệ điều hành cục bộ (trên Unix, /etc/passwd). Thật không may, khi Trung tâm kiểm soát nhắc cho một ID và mật khẩu người dùng, không thể biết rõ được sẽ dùng được nó với một kết nối cơ sở dữ liệu hay để nối tới máy chủ quản trị, và thường khó dự đoán sẽ sử dụng cái nào.
  2. Máy khách Java (JCC) không hỗ trợ trình cắm thêm GSS-API với các phiên bản trước Phiên bản V8 FP11. Từ Phiên bản V8 FP11 trở đi, máy khách Java nguyên gốc kiểu 4 có thể thực hiện một phiên bản Java của trình cắm thêm GSS-API. Tuy nhiên, trình điều khiển kiểu 4 hỗ trợ Kerberos với các phiên bản trước Phiên bản V8 FP11. Lưu ý rằng máy khách JCC không hỗ trợ các trình cắm thêm an toàn dựa vào ID/mật khẩu người dùng tùy chỉnh với các trình cắm thêm an toàn xác thực hoặc tra tìm nhóm tùy chỉnh.
  3. Các sản phẩm DB2 khác (ví dụ như DB2 trên Z-series, I-series, hoặc VM/VSE) không hỗ trợ bất kỳ dạng các trình cắm thêm an toàn nào. Chúng cũng không hỗ trợ phương thức xác thực của trình cắm thêm GSS-API, trừ Kerberos.
  4. Sao chép (replicate) Q không làm việc với các trình cắm thêm an toàn.
  5. Các trình cắm thêm mặc định đi kèm với DB2 không hỗ trợ xác thực LDAP. Vì vậy, để có thể sử dụng xác thực LDAP, bạn cần phải viết trình cắm thêm riêng của bạn và chạy nó với DB2 để sử dụng nó.

Các kịch bản thực tế

Kịch bản 1: Sử dụng các máy khách nâng cấp và mức thấp với trình cắm thêm GSS-API

Bạn có rất nhiều máy khách, một số trong đó được nâng cấp và một số trong đó không được nâng cấp, và tất cả chúng đều muốn sử dụng trình cắm thêm GSS-API trên máy chủ cơ sở dữ liệu. Trước khi sử dụng trình cắm thêm GSS-API, chúng đã sử dụng xác thực máy khách, máy chủ, hoặc server_encrypt. (Ví dụ sau đây sử dụng máy khách mức thấp c1, máy khách V8.2 c2 và máy chủ V8.2 s1 để minh họa kịch bản này).

Máy khách mức thấp c1:

  1. Không cần làm bất cứ điều gì nếu cơ sở dữ liệu không được ghi vào mục lục với máy khách xác thực. Nếu nó được ghi vào mục lục với máy khách xác thực, hãy ghi lại vào mục lục cơ sở dữ liệu mà không cần quy định mệnh đề xác thực, hoặc sử dụng các tùy chọn xác thực máy chủ server hoặc server_encrypt.

Máy khách phiên bản 8.2 c2:

  1. Cài đặt (các) trình cắm thêm GSS-API phía máy khách trong thư mục trình cắm thêm máy khách.

Máy chủ phiên bản 8.2 s2:

  1. Cài đặt (các) trình cắm thêm GSS-API phía máy chủ trong thư mục trình cắm thêm máy chủ.
  2. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu srvcon_gssplugin_list với danh sách theo thứ tự tên trình cắm thêm GSS-API được hỗ trợ. Lưu ý rằng danh sách này nên theo thứ tự ưu tiên.
  3. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu srvcon_auth là GSS_SERVER_ENCRYPT. Điều này sẽ chạy máy chủ để xử lý máy khách mới bằng cách sử dụng trình cắm thêm GSS-API, và vẫn còn sử dụng SERVER_ENCRYPT để xử lý với các máy khách khác (bao gồm cả các máy khách mức thấp) không hỗ trợ trình cắm thêm GSS-API.

Kịch bản 2: Máy khách V8.2 truyền thông với một cơ sở dữ liệu trong một cá thể khác nhau với thiết lập xác thực khác nhau

Kịch bản này sử dụng máy khách phiên bản 8.2 (c1) và ba cơ sở dữ liệu (dbase1, dbase2, dbase3, thuộc về các cá thể tương ứng là inst1, inst2, inst3).

Cá thể inst1 muốn sử dụng srvcon_auth = server_encrypt.

  1. Cài đặt trình cắm thêm xác thực ID/mật khẩu người dùng phía máy chủ (ví dụ, server_upw) trong thư mục trình cắm thêm máy chủ.
  2. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu server_pw_plugin với tên của trình cắm thêm.
  3. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu srvcon_auth cho server_encrypt.

Cá thể inst2 muốn sử dụng srvcon_auth = kerberos.

  1. Cài đặt trình cắm thêm Kerberos phía máy chủ (ví dụ, krb) trong trong thư mục trình cắm thêm máy chủ.
  2. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu srvcon_gssplugin_list với tên của trình cắm thêm Kerberos phía máy chủ.
  3. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu srvcon_auth là Kerberos.

Cá thể inst3 muốn sử dụng srvcon_auth = gssplugin.

  1. Cài đặt trình cắm thêm GSS-API phía máy chủ (ví dụ, krb, gss1, hoặc gss2, hoặc bất kỳ tổ hợp nào) trong thư mục trình cắm thêm máy chủ.
  2. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu srvcon_gssplugin_list với tên của các trình cắm thêm GSS-API phía máy chủ theo thứ tự ưu tiên. Ví dụ, nếu bạn thích gss2 là krb hơn gss1, hãy cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu bằng cách sử dụng srvcon_gssplugin_list 'gss2,krb,gss1'. Lưu ý rằng krb có thể là trình cắm thêm dựa vào Kerberos tương tự từ inst2. Do Kerberos được thực hiện bằng cách sử dụng một cơ sở hạ tầng GSS-API, nên có thể sử dụng nó như một trình cắm thêm GSS-API.
  3. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu srvcon_auth là gssplugin.

Giả sử máy khách muốn giao tiếp với các cơ sở dữ liệu trong cả ba cá thể. Bạn cần phải:

  1. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu clnt_pw_plugin với trình cắm thêm ID/mật khẩu người dùng phía máy khách (ví dụ, clnt_upw).
  2. Cập nhật tham số cấu hình của trình quản lý cơ sở dữ liệu với trình cắm thêm Kerberos phía máy khách (ví dụ, krb).
  3. ICài đặt các trình cắm thêm phía máy khách (clnt_upw, krb và gss2).
  4. Tạo danh mục cơ sở dữ liệu dbase1 (không quy định xác thực, hoặc quy định xác thực là server_encrypt).
  5. Tạo danh mục cơ sở dữ liệu Dbase2 (không quy định xác thực, hoặc quy định xác thực là Kerberos).
  6. Tạo danh mục cơ sở dữ liệu dbase3 (không quy định xác thực, hoặc quy định xác thực là gssplugin).
  7. Ban hành câu lệnh 'connect to dbase1 user <user ID> using <password>' (kết nối với người dùng dbase1 có <ID người dùng> khi sử dụng <mật khẩu> ).
    Kết nối này sẽ sử dụng server_encrypt; trên máy khách nó sử dụng clnt_upw (từ clnt_pw_plugin), và trên máy chủ nó sử dụng server_upw (từ server_pw_plugin).
  8. Ban hành câu lệnh 'connect to dbase2 user <user ID> using <password>' (kết nối với người dùng dbase2 có <ID người dùng> khi sử dụng <mật khẩu> ).
    Kết nối này sẽ sử dụng Kerberos, trên máy khách nó sử dụng krb (từ clnt_krb_plugin) và trên máy chủ nó sử dụng krb (từ rvcon_gssplugin_list).
  9. Ban hành câu lệnh 'connect to dbase3 user <user ID> using <password>'
    Kết nối này sẽ sử dụng gssplugin; trên máy khách nó chọn gss2 mặc dù cả hai gss2 và krb đều được liệt kê; srvcon_gssplugin_list nói rõ thứ tự ưu tiên. Sau đó máy khách sẽ cho máy chủ biết để sử dụng gss2. Như vậy, cả máy khách và máy chủ sẽ sử dụng gss2.

Lưu ý rằng không giống như trình cắm thêm ID/mật khẩu người dùng, trình cắm thêm dựa trên GSS-API cần có cùng tên trên cả máy khách lẫn máy chủ.


Các vấn đề chung làm việc với các trình cắm thêm an toàn

Phần này đưa ra những lời khuyên về các vấn đề gỡ lỗi với các trình cắm thêm an toàn:

Kiểm tra bản ghi nhật ký quản trị với các thông báo đặc trưng cho các trình cắm thêm an toàn. Trên UNIX, kiểm tra sqllib/db2dump/<instance name>.nfy. Trên Windows, sử dụng Event Viewer (Trình xem sự kiện) để xem các bản ghi sự kiện của Windows.

Bảng 9 liệt kê các giá trị của bản ghi quản trị đặc trưng cho các trình cắm thêm an toàn.

Bảng 9. Các giá trị bản ghi quản trị đặc trưng cho các trình cắm thêm an toàn
Giá trị LogLý do
13000Một cuộc gọi đến API trình cắm thêm an toàn GSS-API không thành công do lỗi.
13001Một cuộc gọi đến API trình cắm thêm an toàn DB2 không thành công do lỗi.
13002DB2 đã không tải lên thành công một trình cắm thêm.
13003Tên người ủy thác không hợp lệ.
13004Tên trình cắm thêm không hợp lệ.
13005DB2 đã không tải thành công trình cắm thêm.
13006Đã gặp phải một lỗi trình cắm thêm không mong muốn.

Kiểm tra các thông báo lỗi và giá trị SQLSTATE có liên quan để chẩn đoán cho thông báo đó. Bất kỳ thông báo nào có liên quan đến các trình cắm thêm an toàn sẽ có các giá trị SQLCODE sau:

Bảng 10. SQLCODES có liên đến đến các trình cắm thêm an toàn
SQLCODELý do
-1365Lỗi của trình cắm thêm trong quá trình db2start hoặc db2stop
-1366Vấn đề ủy quyền cục bộ
-30082Các lỗi của trình cắm thêm liên quan đến kết nối

Nếu bạn đang sử dụng trình cắm thêm trên một nền tảng Windows 64-bit và đang thấy các lỗi tải trình cắm thêm, thì hãy đảm bảo rằng các thư viện trình cắm thêm 64-bit có hậu tố '64' trên tên thư viện, còn tham số cấu hình của trình quản lý cơ sở dữ liệu thì không có. Hãy nhớ rằng ứng dụng 32-bit phải sử dụng các trình cắm thêm 32-bit còn các ứng dụng 64-bit phải sử dụng các trình cắm thêm 64-bit.

Ngoài vấn đề nêu trên, bạn có thể gặp các lỗi gây ra bởi các hạn chế của trình cắm thêm an toàn. Tham khảo phần Các hạn chế nêu trên để đảm bảo rằng những gì bạn đang cố gắng thực hiện không phải là một hạn chế DB2 về cách hoạt động của các trình cắm thêm an toàn.


Tóm tắt

Bài này cung cấp cho bạn một cái nhìn tổng quan về các trình cắm thêm an toàn, bắt đầu với các lợi ích của các trình cắm thêm an toàn và lợi thế của chúng trên các phương tiện an toàn tiêu chuẩn. Bài báo này đã giải thích chi tiết các kiểu trình cắm thêm khác nhau được DB2 hỗ trợ và cách bạn thường bắt đầu chạy chúng. Một loạt các ví dụ đi cùng bạn qua việc tạo các kiểu các trình cắm thêm an toàn khác nhau, mã cho các trình cắm thêm này có sẵn để tải về ở dưới đây. Bạn đã tìm hiểu về các hạn chế với các trình cắm thêm an toàn, và các lỗi thường gặp trong lúc làm việc với chúng để giúp bạn gỡ rối các vấn đề khi thực hiện các trình cắm thêm an toàn một mình.


Tải về

Mô tảTênKích thước
Sample code for this articlesecurity.zip16KB

Tài nguyên

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Khi bạn đăng ký với trang developerWorks lần đầu tiên, một tiểu sử của của bạn được tạo ra. Chọn các thông tin về tiểu sử của bạn (tên, nước/vùng, và nơi làm việc) đã được hiện lên màn hình, thông tin này sẽ được hiện kèm với nội dung mà bạn đăng tải. Bạn có thể cập nhật thông tin này bất kỳ lúc nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Information Management
ArticleID=783391
ArticleTitle=An toàn DB2 UDB, Phần 2: Hiểu các trình cắm thêm an toàn của DB2 cho Linux, UNIX và Windows
publish-date=05182011