Hạ tầng hệ thống đăng nhập một lần

cho ứng dụng web, web service

Building Single sign-on infrasture for web, web service

Tóm tắt – Bài báo đề cập đến vấn đề bảo mật cho hệ phân tán không thuần nhất trong

thực tế, đi đến giải pháp xây dựng hạ tầng hệ thống đăng nhập một lần cho các ứng

dụng trong hệ phân tán. Hướng giải quyết ở đây là cài đặt giao thức bảo mật

Kerberos, thực thi qua các giao thức chuẩn Internet như GSS-API, SPNEGO và công

nghệ Microsoft Active Directory. Từ đó, bài báo mô tả hệ thống đăng nhập một lần

trước tiên được xây dựng cho web, web service, làm tiền đề giải quyết cho các giao

thức giao vận khác. Tóm lại, bài báo đã đề ra được một mô hình bảo mật cho hệ phân

tán và thư viện nền tảng nhắm đến các mục tiêu: trợ giúp cho người phát triển ứng

dụng có thể lập trình mà không phải quan tâm đến hoạt động của mức an toàn bảo

mật; đơn giản hoá công việc của nhà quản trị và tạo sự tiện dụng cho người dùng hệ

thống phân tán.

Abstract – This article is concerned with the security problem in real heterogeneous

distributed systems, then propose a solution to build a single sign-on infrastrure for

there applications. The solution aims to set up the Kerberos protocol which is done via

several standard Internet protocols such as GSS-API, SPNEGO and Microsoft Active

Directory technology. This article also mention about our security system built for

web, web service, as an initial ground of other transport protocols. To sum up, this

paper offers a new solution and standard-reference library for security problem of real

distributed systems to support software developers in dealing with secure problems,

simplify administrator’s tasks and enhance user’s experience in using systems.

I. GIỚI THIỆU CHUNG

Ngày nay, các thông tin quan trọng được lưu trữ trên mạng càng nhiều và thường

xuyên được truy nhập từ các máy tính khác trong mạng. Chính những điều này đã và

đang mang lại những lợi ích to lớn cho việc chia sẻ tài nguyên, kết nối trong các tổ

chức doanh nghiệp. Tuy nhiên, do đặc điểm nhiều người sử dụng và phân tán về mặt

địa lý nên việc bảo vệ tài nguyên đó tránh khỏi mất mát, xâm phạm (vô tình hay cố ý)

trong môi trường mạng phức tạp hơn nhiều so với một máy tính đơn lẻ, một người sử

dụng. Chính vì thế công tác an toàn bảo mật cho các hệ thống phân tán thường là phức

tạp và ngày càng trở nên quan trọng.

Đề tài bài báo này xuất phát từ yêu cầu xây dựng hạ tầng bảo mật cho các dịch vụ

trong hệ thống phân tán không thuần nhất. Trong hệ thống này, người dùng có thể truy

nhập vào các dịch vụ đặt phân tán trong mạng chạy trên các hệ điều hành khác nhau

(UNIX, Windows). Chúng ta muốn các máy chủ này có khả năng hạn chế truy nhập

của các người dùng được phân quyền và có khả năng thực hiện chứng thực cho các

dịch vụ. Tuy nhiên, các ứng dụng và dịch vụ trong hệ thống sẽ phát triển một cách

nhanh chóng khi xuất hiện nhu cầu, gây nên sự bất tiện cho người dùng phải nhập lại

thông tin chứng thực mỗi khi truy nhập một dịch vụ.

Đặc biệt, khi mà các ứng dụng cung cấp dịch vụ trong hệ thống khá phức tạp và yêu

cầu về độ bảo mật, an toàn thông tin của hệ thống ngày càng cao. Hệ thống bao gồm

rất nhiều thành phần tương tác với nhau, chạy trên nền các hệ điều hành khác nhau.

Mỗi thành phần module của hệ thống không chỉ được cài đặt trên một máy mà có thể

hoạt động trên rất nhiều máy tính nối mạng với nhau. Chẳng hạn trong Workflow, khi

các dịch vụ web thực thi trong workflow đòi hỏi thông tin chứng thực người dùng từ

các dịch vụ phát sinh yêu cầu phục vụ; hay trong hệ thống tính toán lưới, việc bảo mật

thông tin về công việc gửi đến thực hiện ở các máy tính cá nhân trên mạng cũng hết

sức quan trọng.

Vì thế, cần có một cơ chế nhất quán đảm bảo chứng thực, bảo mật cho việc truyền

thông giữa các module, các dịch vụ trong hệ phân tán. Hệ thống đăng nhập một lần

Single sign-on (SSO) cho phép người dùng chỉ cần một lần khai báo vào hệ thống để

được xác thực định danh người dùng, rồi truy nhập vào nhiều tài nguyên, dịch vụ khác

nhau trong hệ thống phân tán mà không bị ngắt quãng vì phải đǎng ký nhiều lần khi có

yêu cầu.

Kerberos là một giao thức chứng thực được phát triển trong dự án Anthena ở MIT.

Qua quá trình phát triển, nó đã đạt đến độ thuần thục, ổn định; phiên bản 5 giao thức

Kerberos đã được cài đặt trên hầu hết các nền tảng, được sử dụng trong rất nhiều ứng

dụng. Việc sử dụng giao thức Kerberos để xây dựng hệ thống sẽ đảm bảo tính năng

SSO cũng như tính bảo mật cho hệ thống.

Hiện nay, đã có nhiều cài đặt Kerberos KDC như Hemidal, MIT KDC và Microsoft

Active Directory. Tuy nhiên, Active Directory vượt trội hơn hẳn bởi tính hoàn thiện

của nó, tương thích hoàn toàn với RFC1510. Vì thế, ta mong muốn tích hợp với Active

Directory cài đặt Kerberos để tạo ra một nền tảng bảo mật trong suốt, kết hợp UNIX và

Windows. Điều này sẽ được thực hiện thông qua việc thực thi các giao thức chuẩn

Internet trong hệ thống: Web service, SPNEGO/HTTP, GSS-API/Kerberos và LDAP.

II. GIAO THỨC KERBEROS

Kerberos là một giao thức chứng thực mạng được phát triển trong dự án Athena của

học viện công nghệ Massachusetts (MIT). Kerberos là một cơ chế chứng thực mạnh

cho các ứng dụng client/server trên môi trường mạng phân tán; nó cho phép các thực

thể truyền thông trong mạng chứng thực lẫn nhau mà vẫn đảm bảo an toàn, chống nghe

lén hay tấn công dùng lại trên mạng. Nó cũng đảm bảo tính toàn vẹn và tính mật cho

thông tin truyền đi, sử dụng mã hoá bí mật như DES, triple DES.

2.1. Nội dung

Kerberos không xây dựng các giao thức chứng thực phức tạp cho mỗi máy chủ mà

hoạt động dựa trên một máy chủ chứng thực tập trung KDC (Key Distribution Centre).

KDC cung cấp vé cho việc chứng thực người dùng và bảo mật truyền thông bởi khoá

phiên trong vé. KDC gồm:

- Máy chủ chứng thực AS (Authentication Server) biết khoá mật của tất cả người

dùng được lưu giữ trên một cơ sở dữ liệu tập trung.

- Máy chủ cấp khoá TGS (Ticket Granting Server) cung cấp vé dịch vụ cho phép

người dùng truy nhập vào các máy chủ trên mạng.

Giao thức Kerberos hoạt động khá phức tạp, về cơ bản được thực hiện qua ba giai

đoạn, hay ba pha. Trong kịch bản này, người dùng C đăng nhập vào máy trạm client và

yêu cầu truy nhập tới máy chủ V.

Hình 1: Giao thức Kerberos

Pha thứ nhất: Kết nối với AS để lấy về vé xin truy nhập TGS, ticket-granting-ticket

(TGT)

Truyền thông với AS thường là giai đoạn khởi đầu của phiên đăng nhập, nhằm lấy về

dữ liệu chứng thực (TGT) cho TGS, để sau đó lấy về chứng thực cho các máy chủ khác

mà không phải nhập lại khoá bí mật của client. Khoá bí mật của client được sử dụng

cho cả việc mã hoá và giải mã.

a. Người dùng C đăng nhập vào hệ thống, nhập định danh và mật khẩu. Client sẽ

chuyển đổi mật khẩu thành khoá mật của C, lưu trữ trong biến của chương trình. Sau

đó, client gửi yêu cầu xin cấp TGT tới AS bằng thông điệp Kerberos Authentication

Service Request (KRB_AS_REQ) gồm 2 phần :

- Định danh người dùng, định danh TGS nhằm chỉ định sử dụng dịch vụ TGS dưới

dạng bản rõ.

- Dữ liệu tiền chứng thực (pre-authentication data) chứng minh rằng người dùng có

đúng mật khẩu của anh ta. Phần này được mã hoá bằng khoá sinh ra từ mật khẩu

người dùng.

b. AS sẽ truy lục trong cơ sở dữ liệu, lấy khoá bí mật của C, giải mã phần dữ liệu tiền

chứng thực, kiểm tra có hợp lệ không. Nếu có, AS có thể bảo đảm dữ liệu tiền chứng

thực được mã hoá đúng bằng khoá bí mật của C, không bị tấn công dùng lại.

c. Cuối cùng thì AS cũng đã xác minh được định danh của C, AS sẽ phản hồi bằng một

thông điệp Kerberos Authentication Service Response (KRB_AS_REP) có chứa vé

TGT bao gồm :

- Một khoá phiên SK1 dùng cho truyền thông giữa client và TGS ở pha thứ hai,

được mã hoá bằng khoá mật của C đảm bảo chỉ có C mới giải mã được.

- Bản sao của SK1 được mã hoá bằng khoá mật của TGS đảm bảo chỉ TGS đọc

được.

Pha thứ hai: Truyền thông với máy chủ cấp vé dịch vụ TGS, lấy về service ticket truy

nhập máy chủ V

a. Có vé TGT và khóa phiên SK1, C đã sẵn sàng để truy nhập vào TGS. Đầu tiên C gửi

cho TGS một thông điệp Kerberos Ticket Granting Service Request (KRB_TGS_REQ)

có chứa :

- Vé TGT và Định danh dịch vụ yêu cầu V.

- Bộ dữ liệu chứng thực gọi là Authenticator được mã hoá bằng SK1 gồm định

danh người dùng C, IP của client và tem thời gian. Authenticator chỉ sử dụng một

lần và có hiệu lực trong một thời gian cực ngắn.

b. TGS dùng khoá mật của mình giải mã TGT, lấy ra SK1 để giải mã authenticator,

kiểm tra tính hợp lệ. Nếu hợp lệ, TGS được đảm bảo chắc chắn rằng người gửi chiếc vé

chính là chủ nhân thực sự của nó. Khi đó, TGS sẽ sinh ra khoá phiên mới SK2 chung

cho client và máy chủ V. Hai bản sao của khoá phiên này được gửi về cho C bằng

thông điệp Kerberos Ticket Granting Service Response (KRB_TGS_REP) gồm:

- Một bản sao khoá phiên SK2 được mã hoá bằng khoá phiên của C.

- Bản kia được mã hóa bằng khoá mật của V đảm bảo chỉ V mới mở được.

Pha thứ ba: Truyền thông trong chứng thực client/server, trao đổi dữ liệu

a. Bây giờ thì client sẵn sàng chứng thực với máy chủ V. Client gửi cho V một thông

điệp Kerberos Aplication Request (KRB_AP_REQ) có chứa :

- Authenticator mã hoá bởi khoá phiên SK2.

- Service ticket mã hoá bởi khoá mật của V.

- Cờ xác định client có yêu cầu chứng thực lẫn nhau không.

b. V giải mã service ticket, lấy ra SK2 giải mã authenticator, xác minh tính hợp lệ. Nếu

hợp lệ, B xem giá trị cờ yêu cầu chứng thực lẫn nhau. Nếu cờ được thiết lập, V sử dụng

SK2 mã hoá thời gian từ authenticator và gửi về cho C bằng thông điệp

KRB_AP_REP.

c. C giải mã thông điệp bằng khoá phiên dùng chung với V, xác minh thời gian trong

đó có đúng như khi gửi cho V không. Nếu hợp lệ, kết nối truyền thông sẽ được thực

hiện.

Như vậy, khoá phiên đã được chuyển tới server V và client một cách an toàn, được sử

dụng cho việc bảo mật truyền thông giữa client và server về sau. Hơn nữa, cả client và

server đều được chứng thực lẫn nhau, không xảy ra trường hợp giả mạo một trong hai

bên tham gia truyền thông.

2.2. Đánh giá giao thức Kerberos

Qua quá trình phát triển, Kerberos đã đạt đến độ thuần thục, ổn định; phiên bản

Kerberos v5 đã được cài đặt trên hầu hết các nền tảng, được sử dụng trong rất nhiều

ứng dụng. Việc sử dụng giao thức Kerberos để xây dựng hệ thống sẽ đảm bảo những

tính năng sau cho hệ thống:

Tăng cường bảo mật

Khi một phiên truyền thông được thiết lập, khoá phiên sẽ được truyền an toàn đến

các bên truyền thông. Điều này sẽ đảm bảo cho hệ thống các tính năng bảo mật sau:

- Tính xác thực: Không ai gửi một thông điệp sai. Do chỉ có client và máy chủ

dịch vụ có thể biết được khoá phiên nên không thể xảy ra trường hợp có kẻ thứ

ba mạo danh một trong hai bên để tham gia vào phiên truyền thông. Ở đây,

Kerberos đảm bảo tính Chứng thực lẫn nhau.

- Tính riêng tư, tính toàn vẹn: Thông điệp trước khi truyền sẽ được mã hoá và kí

bằng khoá phiên nên thám mã không thể nào có thể đọc hay thay đổi nội dung

thông điệp được truyền.

Như vậy, sử dụng giao thức Kerberos thì ta được đảm bảo tính xác thực, tính riêng

tư, và tính toàn vẹn của các thông điệp được truyền. Đây chính là các yêu cầu cần và

đủ để đảm bảo một phiên truyền thông an toàn. Ngoài ra, Kerberos còn cung cấp một

chức năng quan trọng như sau :

- Hỗ trợ cơ chế uỷ nhiệm:

Trong các ứng dụng đa lớp, khi người dùng yêu cầu một dịch vụ ở tầng giao diện

người dùng, từ đây sẽ gửi yêu cầu đến tầng giữa thực hiện các chức năng của hệ thống

đồng thời tạo ra các giao tác truy vấn tới tầng dữ liệu lấy ra thông tin của người dùng.

Thông thường, các tầng nằm phân tán trong các máy chủ trên mạng nên đều có cơ chế

bảo mật độc lập với nhau.

Hình 2: Hỗ trợ uỷ nhiệm trong Kerberos

Do vé Kerberos có khả năng đại diện vì thế các tầng có thể dùng vé này đại diện

cho người dùng để thực hiện các chức năng được phép. Vì thế, mỗi tiến trình của mỗi

tầng đều có thể xác định chính xác được người dùng mà nó phục vụ, từ đó có cơ chế

phân quyền, auditing phù hợp. Như vậy, với sự hỗ trợ khả năng uỷ nhiệm trong

Kerberos các dịch vụ bảo mật như auditing, phân quyền được thực hiện một cách dễ

dàng.

Cung cấp cơ chế chứng thực mạnh

Mỗi khi đăng nhập vào hệ thống (login vào KDC), người dùng sẽ được cấp một vé

TGT để xin các service ticket cho các lần truy nhập sau vào các máy chủ dịch vụ trong

hệ thống. Tức là với vé TGT, người dùng không cần phải nhập định danh, mật khẩu

thêm một lần nào nữa, vì lý do này giao thức Kerberos còn gọi là giao thức Đăng nhập

một lần (Single sign-on).

Ta sẽ đánh giá các điểm của năng SSO theo cả ba quan điểm: của người dùng, của

nhà quản trị, nhà phát triển hệ thống. Theo đó, Kerberos :

- Tăng sự tiện dụng cho người dùng: Người dùng không cần phải đăng nhập

nhiều lần khi sử dụng hệ thống, cũng như không cần phải nhớ quá nhiều mật

khẩu cho các dịch vụ trong hệ thống. Tất cả chỉ là một tài khoản cho hết thảy

các dịch vụ trong hệ thống.

- Hỗ trợ các nhà phát triển hệ thống: SSO cung cấp một framework chứng thực

chung cho các nhà phát triển. Vì thế họ không cần phải quan tâm đến chứng

thực khi xây dựng hệ thống nữa, coi như là các yêu cầu gửi đến hệ thống đã

được chứng thực. Điều này sẽ làm cho các nhà phát triển hoàn toàn yên tâm về

an ninh của hệ thống được xây dựng, mà tránh được công việc nặng nhọc là xây

dựng an toàn bảo mật cho hệ thống mới.

- Làm đơn giản hoá công tác quản trị: Theo truyền thống, mỗi ứng dụng có cơ sở

dữ liệu người dùng riêng phục vụ cho cơ chế chứng thực độc lập của nó, nên khi

các hệ thống tham gia vào mạng, số lượng người dùng sẽ tăng lên rất nhanh làm

quá tải công tác quản trị. Với SSO, mọi hệ thống sử dụng cùng cơ sở dữ liệu

người dùng tập trung vì thế công tác quản trị đã được tập trung hoá, số lượng

người dùng giảm đi rất nhiều.

- Tăng cường bảo mật: Hệ thống SSO có cơ chế chứng thực an toàn cũng như bảo

mật truyền thông trên mạng. Giảm thiểu số lần nhập mật khẩu cũng có nghĩa là

tăng độ an toàn cho hệ thống vì với số lượng mật khẩu nhiều người dùng thường

ghi mật khẩu ra xung quanh, dễ để lộ.

Tuy nhiên, bất kỳ hệ thống bảo mật nào cũng không thể chống lại tất cả các kiểu

tấn công của hacker, Kerberos cũng có những nhược điểm nhất định như:

- Khó tích hợp với các hệ thống cũ: thường thì các hệ thống sẵn có trong mạng đã

có cơ chế chứng thực riêng, cũng như cơ sở dữ liệu thông tin người dùng riêng.

Vì thế, việc tích hợp hệ thống cũ vào hệ SSO không tránh khỏi phải sửa lại mã

chương trình hệ thống cũng như di chuyển, thay đổi cơ sở dữ liệu người dùng.

- Tấn công ở desktop: Cũng do tính năng SSO, có khả năng kẻ địch giành được

quyền truy nhập tới các tài nguyên khi người dùng của máy đó rời khỏi máy sau

khi đăng nhập mà quên không khoá máy lại. Hệ thống SSO chỉ bảo mật trên

đường truyền mà không bảo mật cho dữ liệu trước khi được truyền nên mật

khẩu của người dùng rất có khả năng bị các chương trình như trojan đánh cắp,

giành quyền truy nhập hệ thống.

- Điểm yếu trong mạng: Với đăng nhập một lần, dịch vụ chứng thực sẽ được sử

dụng bởi tất cả các ứng dụng trong mạng. Vì thế, dịch vụ này rất dễ bị tấn công

DoS, làm tê liệt cả hệ thống.

Như vậy, ta đã thấy được sự phù hợp khi sử dụng giao thức Kerberos cho việc bảo

mật cho hệ thống phân tán. Trong mục tiếp theo, ta sẽ trình bày những nghiên cứu các

công nghệ, giao thức, giải pháp phục vụ cho việc thực hiện cài đặt giao thức Kerberos

trong hệ thống.

III. CÁC GIAO THỨC QUAN TRỌNG

Mục này sẽ tập trung trình bày các công nghệ, giao thức phục vụ cho việc tích hợp

được môi trường bảo mật Kerberos. Việc tích hợp đó thể hiện ở những khía cạnh sau:

- Yêu cầu và phát sinh thẻ bài bảo mật Kerberos

- Gắn thẻ bài Kerberos vào thông điệp truyền

- Tạo ra một ngữ cảnh an toàn

- Kí, mã hoá thông điệp theo ngữ cảnh an toàn

GSS-API là phương pháp truyền thống để giải quyết vấn đề trên, khi mà hai bên

truyền thông an toàn với nhau trong một ngữ cảnh an toàn theo giao thức Kerberos. Vì

thế, trong phần đầu của mục này, chúng ta đi vào tìm hiểu GSS-API về những lợi

điểm, các dịch vụ bảo mật cung cấp và cả hạn chế của nó.

3.1. Giao thức GSS-API

GSS-API (Generic Security Service – Application Programming Interface) được tổ

chức IETF nghiên cứu và soạn thảo nhằm cung cấp một mô hình giải pháp chung cho

bài toàn chứng thực, phân quyền, đảm bảo an toàn dữ liệu khi truyền, chống replay, và

hỗ trợ việc giao giấy ủy nhiệm (RFC 2743). GSS-API được mô tả không phụ thuộc vào

ngôn ngữ thực thi nó. GSS-API chỉ mô tả các giao diện lập trình bên trên còn chi tiết

bên dưới cơ chế đảm bảo an toàn thông tin có thể tùy ý lựa chọn.

Một trong những tính năng quan trọng của GSS-API đó là nó dựa trên các thẻ bài,

được sử dụng các để thực hiện việc chứng thực và mã hóa các thông tin cần thiết.

Tóm lại, GSS-API thực hiện hai nhiệm vụ cơ bản:

Hình 3: GSS-API Layer

- Tạo ra một ngữ cảnh an toàn (security context) cho phép trao đổi dữ liệu giữa

hai bên truyền thông. Một ngữ cảnh an toàn có thể được hiểu là sự tin tưởng

giữa hai bên, các ứng dụng có thể chạy trong cùng một ngữ cảnh xác định được

bên kia, từ đó cho phép truyền dữ liệu cho nhau trong khi ngữ cảnh còn tồn tại.

- GSS-API có thể thực thi một hay nhiều kiểu bảo vệ (security services) cho dữ

liệu được truyền.

Tính khả chuyển ứng dụng với GSS-API

GSS-API hỗ trợ tính khả chuyển cho các ứng dụng như sau:

- Độc lập với các cơ chế bảo mật: GSS-API cung cấp một giao diện chung cho

bảo mật. Bằng cách chỉ ra cơ chế bảo mật ngầm định, ứng dụng sẽ được bảo

đảm an toàn mà không cần phải quan tâm đến cơ chế bảo mật chạy dưới hay bất

kỳ thông tin chi tiết nào về cơ chế đó.

- Độc lập với giao thức giao vận: GSS-API độc lập với các giao thức giao vận, vì

thế GSS-API có thể sử dụng cho các ứng dụng sử dụng socket, RPC hay

TCP/IP.

- Độc lập với nền tảng: GSS-API hỗ trợ bởi hầu hết các nền tảng, nó có thể áp

dụng cho ứng dụng chạy trên bất cứ hệ điều hành nào.

- Độc lập với QoP (Quality of Protection): QoP tham chiếu tới kiểu thuật toán mã

hoá, sinh ra các thẻ mật mã. GSS-API cho phép người lập trình bỏ qua QoP

bằng cách sử dụng giá trị ngầm định, trong trường hợp cần thiết thì có thể chỉ ra.

Các dịch vụ bảo mật trong GSS

GSS-API cung cấp ba dịch vụ bảo mật như sau:

- Chứng thực: Đây là dịch vụ cơ bản của GSS-API.

- Đảm bảo tính toàn vẹn: Tính toàn vẹn là sự xác minh tính đúng đắn của dữ liệu.

Ngay cả khi dữ liệu được gửi đi từ một người dùng hợp lệ thì dữ liệu dữ liệu

không thể nào bị thay đổi hay xâm hại. Tính toàn vẹn bảo đảm rằng dữ liệu

được toàn vẹn như ban đầu, không bị thêm hay bớt đi phần nào. GSS-API đảm

bảo tính toàn vẹn của dữ liệu bằng việc thêm vào thẻ mật mã MIC (Message

Integrity Code). MIC chứng minh rằng dữ liệu nhận được toàn vẹn như khi

được gửi đi.

- Đảm bảo tính mật: GSS-API đảm bảo tính mật của dữ liệu vì các cơ chế bảo

mật bên dưới có khả năng mã hoá dữ liệu, do đó không có kẻ thứ ba nào có thể

đọc được dữ liệu khi nó truyền đi.

Các cơ chế trong GSS-API

GSS-API được thiết kế cho phép một thực thi của nó có thể đồng thời hỗ trợ nhiều

cơ chế bảo mật trong đó có hai cơ chế bảo mật chuẩn được IETF định nghĩa Kerberos

và SPKM (Simple Public Key Mechanism).

Hình 4: Mô hình GSS-API

Mỗi cơ chế bảo mật được định danh bởi một số nhất định (OID - Object Identifier)

đã được đăng ký trước với tổ chức IANA. Cơ chế Kerberos V5 được định danh bởi

OID {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)

krb5(2)} = 12840113554122. Vì vậy, để sử dụng giao thức chứng thực Kerberos bên

dưới, ứng dụng chỉ cần chỉ ra OID của cơ chế là 12840113554122.

Hạn chế của GSS-API

GSS-API tạo ra một giao diện chung cho các cơ chế chứng thực khác nhau vì thế,

nếu các bên truyền thông có được các giấy chứng thực GSS-API của cùng một cơ chế

chứng thực thì một ngữ cảnh an toàn của cơ chế đó sẽ tạo ra cho truyền thông giữa

chúng. Tuy nhiên, GSS-API không quy định phương thức mà hai bên truyền thông

thiết lập khi chúng có chung một cơ chế bảo mật. Vì thế, ITFE đã đưa ra giao thức

SPNEGO cho việc thương lượng sử dụng cơ chế chứng thực bên dưới.

3.2. Giao thức SPNEGO

Giao thức Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) được

định nghĩa là một cơ chế giả an toàn, định danh bởi OID (object indentifier)

iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) cho phép hai bên truyền

thông có thể chỉ định cơ chế bảo mật khi chúng có chung các cơ chế bảo mật GSS-API,

và triệu gọi việc thiết lập các ngữ cảnh an toàn (security context) cho cơ chế bảo mật

được chọn. Điều này rất hữu ích cho các ứng dụng sử dụng các cài đặt GSS-API hỗ trợ

nhiều cơ chế bảo mật khác nhau.

SPNEGO cho phép thương lượng các cơ chế bảo mật khác nhau, các tuỳ chọn khác

nhau trong cùng một cơ chế hoặc giữa các cơ chế bảo mật. Khi một cơ chế bảo mật

chung được chỉ định, nó có thể thương lượng các tuỳ chọn riêng trong khi security

context của nó được thiết lập. Việc này xảy ra trong các thẻ bài của cơ chế đó và độc

lập với giao thức SPNEGO.

SPNEGO thực thi dựa trên mô hình thương lượng sau: Bên khởi xướng đề nghị một

cơ cơ chế bảo mật hoặc một danh sách có thự tự các cơ chế bảo mật, bên thứ hai sẽ

chấp nhận cơ chế được đề xuất hay chọn ra một cơ chế trong danh sách đề xuất, hoặc

từ chối các đề xuất đó; và thông báo cho bên khởi xướng quyết định của nó.

Trong dạng thức cơ bản, SPNEGO sẽ yêu cầu thêm một round trip. Tuy nhiên, việc

thiết lập kết nối mạng là một đặc trưng hiệu suất then chốt của bất kỳ hạ tầng mạng nào

và thêm một round trip trên các kết nối WAN, mạng radio gói … sẽ giảm hiệu suất

mạng một cách đáng kể. Để tránh round trip thêm đó, thẻ bài đầu tiên của cơ chế được

bên khởi xướng chỉ định sẽ được nhúng vào trong thẻ bài đầu tiên của SPNEGO. Vì

thế, nếu bên thứ hai đồng ý thì không cần thêm một round trip nào trong giao thức

thương lượng nữa.

SPNEGO sử dụng các khái niệm sử dụng trong đặc tả GSS-API. Các dữ liệu

thương lượng được đóng gói trong các thẻ bài context-level. Vì thế, các bên không cần

phải biết đến sự tồn tại của các thẻ bài thương lượng cũng như có cơ chế giả an toàn

mới. Thất bại trong pha thương lượng sẽ trả về mã GSS_S_BAD_MECH.

Hình 5: Giao thức SPNEGO

Mô tả việc thương lượng

Mỗi OID định danh cho một cơ chế GSS-API hoặc các biến thể của chúng.

- Khi một cơ chế bảo mật được đề xuất bởi bên khởi xướng, nó đại diện cho cơ

chế bảo mật duy nhất được hỗ trợ/lựa chọn bởi bên khởi xướng.

- Khi có nhiều cơ chế bảo mật được đề xuất bởi bên khởi xướng, chúng sẽ đại

diện cho một tập các cơ chế bảo mật được hỗ trợ/lựa chọn bởi bên khởi xướng.

Thẻ bài SPNEGO đầu tiên (NegTokenInit) do bên khởi xướng gửi có chứa một

danh sách các cơ chế bảo mật, một tập các tuỳ chọn (deleg, replay, conf flags) phải

được hỗ trợ bởi cơ chế đề nghị và thẻ bài bảo mật cho cơ chế do bên khởi xướng đề

nghị.

Thẻ bài thương lượng hồi đáp (NegTokenTarg) được gửi đi bởi bên nhận chứa kết

quả thương lượng (ACCEPT_COMPLETED, ACCEPT_IMCOMPLETE, REJECT) và có cả cơ

chế đồng ý trong trường hợp chấp thuận. Nó có thể cũng bao gồm cả hồi đáp cho thẻ

bài đầu tiên của bên khởi xướng, khi cơ chế đề nghị đầu tiên được chấp thuận. Trong

trường hợp ngược lại, nó chỉ việc bỏ qua responseToken trong hồi đáp đầu tiên.

Thủ tục thương lượng

Quá trình thương lượng diễn ra như sau:

(a). Bên khởi xướng sẽ triệu gọi phương thức GSS_Init_sec_context như thông thường,

nhưng các yêu cầu của SPNEGO sẽ được sử dụng.

(b). Bên khởi xướng sẽ phát đi một thẻ bài thương lượng chứa một danh sách các cơ

chế bảo mật được hỗ trợ cho các giấy chứng thực được sử dụng cho thiết lập context,

và thẻ bài cơ chế đề nghị (tuỳ chọn) từ danh sách này, chỉ định trạng thái

GSS_S_CONTINUE_NEEDED.

(c) Bên khởi xướng gửi thẻ bài tới bên nhận.

(d) Bên nhận giữ lại thẻ bài này trong suốt thời gian triệu gọi phương thức

GSS_Accept_sec_context. Phía nhận sẽ phát ra một thẻ bài của cơ chế mà nó hỗ trợ

trong đề nghị.

Nếu cơ chế được chọn bởi bên nhận trùng với cơ chế được chỉ định bên khởi xướng

thì thẻ bài thương lượng có thể chứa một thẻ bài cho cơ chế đó.

Nếu cơ chế chỉ định bởi bên khởi xướng được bên nhận chấp thuận,

GSS_Accept_sec_context() chỉ định GSS_S_CONTINUE_NEEDED khi chứng thực lẫn

nhau hoặc một bên đã được thực hiện và bao gồm cả một thẻ bài đơn trong mỗi hướng

truyền đi hay nhận về.

3.3. Kết luận

Như vậy, sự kết hợp giữa hai giao thức GSS-API và SPNEGO để thực thi Kerberos sẽ

mang đến cho hệ thống một nền tảng bảo mật mở, hoàn toàn tuân theo chuẩn Internet

của tổ chức ITFE. Một lý do nữa là giao thức Kerberos sẽ thay đổi liên tục theo các

phiên bản để hoàn thiện (hiện tại là phiên bản 5), GSS-API là framework chuẩn để thực

hiện giao thức Kerberos giữa các hệ thống khác nhau mà có thể khắc phục được nhược

điểm này.

IV. GIẢI PHÁP ĐĂNG NHẬP MỘT LẦN

Từ những nghiên cứu ở trên, chúng tôi đã xây dựng thư viện bảo mật chung JAAM

(Java Authentication and Authorization Module) đã được xây dựng để thực hiện:

chứng thực, phân quyền, bảo mật thông qua việc cài đặt các giao thức SPNEGO, GSS-

API (Kerberos) và chính sách phân quyền. Từ đó, hệ thống đăng nhập một lần sẽ thực

thi bảo mật ở mức thông điệp, tránh phụ thuộc vào giao thức truyền thông, giao thức

truyền thông chỉ có nhiệm vụ vận chuyển thẻ bài nhằm áp dụng được cho mọi ứng

dụng sử dụng các giao thức truyền thông khác nhau trong hệ thống.

Hình 6: Mô hình sử dụng dụng thư viện JAAM

Các ứng dụng sẽ sử dụng các khối chức năng mà JAAM cung cấp thông qua việc gọi

JAAM qua giao diện lập trình JAAM API. Thư viện JAAM được cài đặt bằng ngôn

ngữ Java, trên nền J2SDK 1.4.2, nhằm đảm bảo có thể sử dụng cho các ứng dụng trên

các nền tảng Windows, Unix, Linux. Kiến trúc của JAAM, về cơ bản, gồm 4 môđun cơ

sở kết hợp với nhau đề thực hiện 4 chức năng cơ bản: chứng thực, phân quyền, uỷ

nhiệm, mã hoá và kí.

- Khối Nego: cài đặt giao thức SPNEGO thực hiện việc thương lượng cho việc

chọn giao thức Kerberos để thực thi ở GSS-API.

- Khối Auth: sử dụng thư viện JGSS-API của J2SDK 1.4.2 để thực hiện chứng

thực, uỷ nhiệm theo giao thức Kerberos qua GSS-API.

- Khối Policy: Thực hiện việc phân quyền người dùng thông qua việc giải mã

thông tin PACs (chỉ có ở Active Directory) và đối sánh cài đặt chính sách phân

quyền của hệ thống.

- Khối Crypto: Cung cấp các chức năng mã hoá, kí thông điệp dựa trên khoá mật

của người dùng.

Hình 7: Kiến trúc JAAM

Từ thư viện JAAM đã có ta sẽ đề ra mô hình hoạt động cho web, web service, là hai

giao thức quan trọng cho việc giải quyết vấn đề nền tảng. Việc cài đặt JAAM cho hai

giao thức này phải đảm bảo được hai yêu cầu sau:

- Độc lập với ứng dụng. Tính độc lập với ứng dụng sẽ giúp các nhà phát triển dễ

dàng hơn trong việc tạo ra các ứng dụng cũng như yên tâm hơn về sự an toàn

của hệ thống.

- Dễ tích hợp vào hệ thống cũ. Đây là một tính năng quan trọng khi cài đặt hệ

thống lên nền hệ thống cũ, dễ tích hợp sẽ làm tăng khả năng tương thích, tái sử

dụng các dịch vụ sẵn có.

4.1. Cài đặt JAAM cho Web

Giao thức SPNEGO đã được hỗ trợ ở tất cả các trình duyệt phổ biến như Firefox,

Microsoft Internet Explorer, Mozila. Vì vậy, công việc của ta là chỉ cài đặt JAAM cho

các ứng dụng Web phía server.

Trong đặc tả phiên bản servlet 2.3 đã đưa ra một cơ chế lọc rất linh động, xử lý theo

cơ chế chuỗi, các bộ lọc (filter) chỉ cần khai báo trong Web.xml mà không phải thay

đổi mã nguồn của ứng dụng web. Các request yêu cầu các servlet, các trang JSP,

HTML trước khi truy nhập đến tài nguyên yêu cầu thì phải đi qua các bộ lọc là các

mođun chứng thực, phân quyền cài sẵn xử lý trước. Chính vì những đặc điểm trên, ta

có thể cài đặt mođun thực hiện chứng thực, phân quyền hoàn cho các request một cách

độc lập với các ứng dụng web. Từ đây, ta đề xuất mô hình bảo mật cho ứng dụng web

như sau:

Hình 8: Mô hình cài đặt JAAM cho Web

Ở phía Web Server, khi có request đến thì sẽ bị servlet filter định hướng (redirect)

sang JAAM (Java Authentication and Authorization Module. Tại JAAM, quá trình

thực hiện chứng thực sẽ đọc header của request, chứng thực theo giao thức

SPNEGO/Kerberos đồng thời cũng thực hiện auditing (logging). Nếu quá trình này

thành công, JAAM lấy thông tin phân quyền trong Kerberos ticket đối sánh với policy

của hệ thống. Thành công ở JAAM, request sẽ được trả về trang web yêu cầu.

4.2. Cài đặt JAAM cho Web Service

Xuất phát từ ý tưởng kiến trúc Web Service, khi muốn cài đặt một dịch vụ web

service thì ta phải đăng kí với UDDI server… Hệ thống của ta sẽ đảm bảo tính độc với

ứng dụng khi nó đảm nhiệm vai trò quản lý kết nối web service giữa client và server.

Ở phía client, khi ứng dụng phát sinh nhu cầu sử dụng một dịch vụ service n phía

server, nó sẽ gửi các thông số như tên dịch vụ, các tham số cho WSClient.WSClient

đóng gói thông tin nhận được thành các gói XML có định dạng thiết kế trước cho

server; tất nhiên gói có chứa cả thông tin chứng thực theo giao thức Kerberos cho

server.

Hình 9: Mô hình cài đặt JAAM cho Webservice

Yêu cầu theo gói XML đến sẽ được WSListener trong JAAM phía server bắt lấy,

thực hiện bóc tách phân tích thông tin. Tiếp đó, WSListener sẽ thực hiện chứng hiện

chứng thực client theo giao thức Kerberos. Nếu chứng thực thành công, WSListener sẽ

tạo một thể hiện của lớp cung cấp dịch vụ service n để thực hiện chức năng yêu cầu,

việc này được thực thi qua truy vấn file ServiceMap.xml đã được thiết đặt. Kết quả trả

về sẽ được đóng gói XML theo chuẩn của hệ thống, gửi về cho Client. WSClient nhận

gói thông điệp trả về, thực hiện bóc tách, phân tích thông tin và trả kết quả về cho ứng

dụng.

Nhận xét: Sự hiện diện của file ServiceMap.xml đã làm cho việc thực thi các dịch

vụ trên Web Service Server một cách chính xác và độc lập; khi xuất hiện nhu cầu cài

đặt một dịch vụ thì thay vì phải cài đặt dịch vụ web theo trình tự thì ta chỉ cần khai báo

nó trong file ServiceMap.xml. Toàn bộ việc truyền thông, thực hiện chứng thực phân

quyền trong hệ thống đều do WSListener, WSClient đảm nhiệm.

4.3. Cài đặt thực nghiệm

Giả sử trong hệ thống mạng của ta có hai ứng dụng cung cấp dịch vụ qua giao diện

Web cho người dùng.

Ứng dụng thứ nhất, ứng dụng web “simple”: Là một servlet hiển thị các thông tin

chứng thực, phân quyền cho người dùng truy cập đến. Cung cấp các kết nối đến các

dịch vụ trong hệ thống, cụ thể ở đây là dịch vụ thứ hai.

Ứng dụng thứ hai, ứng dụng web “hello”: Là một ứng dụng web đa lớp, tuỳ thuộc vào

người dùng có role là “Student” hay “Professor” mà có lời chào tương ứng (“Hello,

student”, “Hello, Professor”). Ứng dụng web này không tự thực hiện lời chào mà lấy

chúng bằng cách truy vấn hai dịch vụ khác trên mạng thông qua Web Service :

- Dịch vụ web “Student”: chỉ cho phép người dùng có role “Student” truy nhập qua

web service, trả về kết quả “Hello, student” + tên sinh viên.

- Dịch vụ web “Professor”: chỉ cho phép người dùng có role “Professor” truy nhập

qua web service, trả về kết quả “Hello, professor” + tên giáo viên.

Hình 10: Mô hình cài đặt thử nghiệm

Như vậy, ứng dụng web “hello” đã phải sử dụng định danh của người dùng có

thuộc nhóm “Student” hay “Professor” để truy nhập vào dịch vụ web tương ứng. Bản

thân ứng dụng web này không thể tự dùng định danh của của mình để truy nhập được

vì hiển nhiên nó không có quyền !

V. KẾT LUẬN

Bảo mật trong hệ phân tán ngày càng được quan tâm đặc biệt khi mà các hệ thống

mạng trong các cơ quan, tổ chức phát triển, cài đặt nhiều ứng dụng phức tạp. Bài báo

đã đưa ra một giải pháp bảo mật khá hoàn chỉnh dựa trên giao thức Kerberos được hỗ

trợ trong rất nhiều hệ thống lớn hiện nay. Hệ thống hiện tại đã đáp ứng được yêu cầu

an toàn, bảo mật tuy nhiên, để phát triển một hệ bảo mật đầy đủ, có khả năng ứng dụng

tốt hơn trong thực tế cần có các hướng phát triển : xây dựng hệ quản trị định danh, đưa

hệ thống lên hoạt động trên Internet. Chúng tôi sẽ tiếp tục hoàn thiện trong thời gian

tới.

TÀI LIỆU THAM KHẢO

[1]. Stallings, W. ”Cryptography and Network Security: Principles and Practice”, 2nd

edition. Prentice Hall, 1999

[2]. Nguyễn Thúc Hải, ”Mạng máy tính và hệ thống mở”. Nhà xuất bản Giáo Dục, năm

1994

[3]. Sanj Surati & Michael Muckin, “HTTP-Based Cross-Platform Authentication via

the Negotiate Protocol”, 2002

[4]. Single Sign-On in Windows 2000 Networks,White Paper, 2000

[5]. Jill Spealman, “Microsoft Windows 2000 Active Directory Services”, Microsoft

Press, 2000

[6]. RFC 1510 The Kerberos Network Authentication Service V5, Internet Engineering

Task Force (IETF), Sep. 1993.

[7]. RFC 1508 "Generic Security Service Application Program Interface"

[8]. RFC 1964 "The Kerberos Version 5 GSS-API Mechanism"

[9]. RFC 2078 "Generic Security Service Application Program Interface,version 2"

[10]. RFC 2478 "Simple and Protected GSS-API Negotiation Mechanism"

[11]. Web Services Security-Kerberos Token Profile:

http://www.oasis-open.org/committees/download.php/1049/WSS-Kerberos-03.pdf

[12]. Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access

Control to Resources, Brezak, Microsoft Corporation, Feb. 2002.

[13]. Transfer Syntax NDR, from CDE 1.1: Remote Procedure Call, The Open Group,

1997.

14]. Jarapac – DCE/RPC in Java, Source Forge, 2004, http://jarapac.sourceforge.net/

[15]. SAMBA Project Documentation, April 2003, Chapter 12. Group Mapping MS

Windows and UNIX, J.F. Micouleau, G. Carter,

http://info.ccone.at/INFO/Samba/groupmapping.html#id2909853

[16]. What Is A Group, Wiki article, K.Brown,

http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAGroup.html

[17]. PAC (Privilege Access Certificate) in a Java Web Server World, 2005, Friis,

http://appliedcrypto.com/spnego/pac/ms_kerberos_pac.html

[18]. Introduction to JAAS and Java GSS-API Tutorials :

http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/

[19]. Single Sign-on Using Kerberos in Java :

http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html

[20]. Prof John Larmouth, “ASN.1 Complete”, 1999

[21]. Eric Armstrong, Stephanie Bodoff, Debbie Carson, “The Java Web Services

Tutorial”. Addison Wesley, 2003

[22]. Li Gong, Gary Ellison, Mary Dageforde, “Inside Java™ 2 Platform Security

Architecture : API Design, and implementation”, 2nd Edition. Addison Wesley Press,

2003

[23]. MIT Kerberos Web Site: http://web.mit.edu/kerberosQ/www

[24]. Các tài liệu hữu ích từ: http://appliedcrypto.com