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

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 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 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. Về đầu trang 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 Về đầu trang 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 Ô 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êm Mô 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. Về đầu trang 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ủ. 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. Về đầu trang 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. Về đầu trang 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: o sqllib/include/db2secPlugin.h o 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. o 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. o 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 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 Hình 7. Trình cắm thêm máy khách Hình 8. 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