86457973 single sign on
TRANSCRIPT
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