You are on page 1of 136

LỜI CẢM ƠN

Lời cảm ơn đầu tiên, chúng em xin kính gửi lòng biết ơn chân thành đến ông
bà, cha mẹ đã nuôi dưỡng và dạy bảo để chúng em có ngày hôm nay.

Xin cảm ơn quý Thầy, Cô trường Đại học Nông Lâm TP.HCM, đặc biệt là
các Thầy, Cô Khoa Công Nghệ Thông Tin đã tận tình truyền đạt những kiến thức và
kinh nghiệm cho chúng em trong suốt thời gian học tập tại trường.

Cảm ơn thầy, thạc sĩ Lê Phi Hùng đã tận tình hướng dẫn chúng em trong
suốt thời gian thực hiện đề tài này.

Cảm ơn thầy Nguyễn Đức Công Song cùng hai bạn Thái Tuyền và Trần
Bảo Hưng đã giúp đỡ nhóm triển khai thực tế hai hệ thống Liferay và Sakai.

Xin cảm ơn các bạn trong lớp DH05DT đã chia sẻ, giúp đỡ và động viên
chúng tôi trong suốt thời gian học tập tại trường cũng như trong thời gian thực hiện
đề tài.

Mặc dù chúng em đã cố gắng hoàn thành đề tài này với tất cả nỗ lực, nhưng
vẫn không tránh khỏi những thiếu sót nhất định. Kính mong nhận được sự chỉ bảo
của quý Thầy, Cô và sự góp ý chân thành của các bạn.

Kính chúc quý thầy cô mạnh khỏe, tiếp tục đạt được nhiều thắng lợi trong
giảng dạy, trong nghiên cứu khoa học và trong sự nghiệp trồng người.

Xin chân thành cảm ơn !

Sinh viên thực hiện


Phạm Thị Ngọc Hơn
Bùi Minh Phúc
Nguyễn Quốc Tân
Phạm Thị Mai Thu

i
DANH SÁCH CHỮ VIẾT TẮT
SSO Single Sign On

OpenSSO Open Single Sign On

ESSO Enterprise Single Sign On

CAS Central Authentication Service

JDK Java Development Kit

J2EE Java 2 Platform, Enterprise Edition

LDAP Lightweight Directory Access Protocol

URI Uniform Resource Identifier

URL Uniform Resource Locator

LMS Learning Mangement System

Sakai CMS Sakai Course Management System

API Application Programming Interface

CSDL Cơ Sở Dữ Liệu

ii
MỤC LỤC
TỔNG QUAN............................................................................................................1
NỘI DUNG BÁO CÁO..............................................................................................2
Chương .1 Tìm hiểu Single Sign On.......................................................................2
.1.1. Single Sign On............................................................................................2
.1.1.1 Khái niệm............................................................................................2
.1.1.2 Lợi ích. ...............................................................................................2
.1.1.3 Các giải pháp Single Sign On..............................................................3
.1.2. Open Single Sign On Enterprise.................................................................3
.1.2.1 Giới thiệu.............................................................................................3
.1.2.2 Triển Khai............................................................................................6
.1.2.3 Tạo user và group trong OpenSSO....................................................13
.1.2.4 Tạo Agent Profile Trong OpenSSO...................................................15
.1.2.5 Cài đặt Policy Agent 3.0....................................................................17
.1.2.6 Bảo vệ ứng dụng Java EE Application với OpenSSO Policy Agents.
......................................................................................................................21
.1.3. Central Authenticate Service (CAS).........................................................22
.1.3.1 Giới thiệu...........................................................................................22
.1.3.2 Triển Khai..........................................................................................33
.1.4. Các giải pháp bảo mật ứng dụng...............................................................46
.1.4.1 Triển Khai...........................................................................................46
Chương .2 Tìm hiểu Sakai LMS...........................................................................50
.2.1. Giới thiệu Sakai project............................................................................50
.2.2. Tính năng..................................................................................................51
.2.3. Bộ công cụ để dạy và học, quản lý điểm số..............................................52
.2.3.1 Syllabus – Đề cương bài giảng..........................................................52
.2.3.2 Gradebook – Sổ điểm........................................................................53
.2.3.3 Assignment – Bài tập.........................................................................58
.2.3.4 Tests and Quizzes – Kiểm tra............................................................63
.2.3.5 Presentation – Trình diễn slide bài giảng...........................................67

iii
.2.4. Bộ công cụ giao tiếp giữa giảng viên và sinh viên....................................68
.2.4.1 Announcement – Thông báo..............................................................68
.2.4.2 Schedule – Lịch công tác...................................................................69
.2.5. Hiện thực Sakai Course Management System (Sakai-CMS)....................71
.2.5.1 Giới thiệu Sakai CMS........................................................................71
.2.5.2 Một số khái niệm trong Sakai CMS...................................................72
.2.5.3 Hiện thực Sakai CMS........................................................................74
.2.5.4 Demo. ...............................................................................................74
.2.6. Triển khai một ứng dụng viết thêm cho Sakai..........................................74
.2.6.1 Cài đặt một ứng dụng từ bên ngoài vào Sakai...................................74
.2.6.2 Viết một ứng dụng trong Sakai..........................................................76
.2.6.3 Triển khai..........................................................................................78
Chương .3 Giới thiệu Portal – Liferay..................................................................79
.3.1. Portal là gì?...............................................................................................79
.3.2. Giới thiệu về Liferay................................................................................81
.3.2.1 Giới thiệu...........................................................................................81
.3.2.2 Hướng dẫn Việt-hóa Liferay.............................................................82
.3.2.3 Tạo theme mới cho Liferay................................................................82
.3.2.4 Chuyển 1 ứng dụng web thành portlet...............................................83
.3.2.5 Quản lí nội dung với CMS..................................................................86
Chương .4 Xây dựng FIT Portal dựa trên Liferay Portal......................................89
.4.1.1 Giới thiệu...........................................................................................89
.4.1.2 Các vai trò (role), hệ thống người dùng sẵn có trong Liferay............89
.4.1.3 Các role, hệ thống người dùng xây dựng thêm trong FIT portal........90
.4.1.4 Đối tượng người dùng trong hệ thống FIT portal...............................91
.4.1.5 Quy trình tạo mẫu tin của hệ thống FIT portal...................................94
.4.1.6 Cài đặt các trang trong hệ thống........................................................95
.4.1.7 Cách tạo Website đơn vị..................................................................111
.4.1.8 Danh mục các website đơn vị..........................................................114
Chương .5 Kết quả đạt được và hướng phát triển...............................................116
.5.1. Kết quả đạt được.....................................................................................116
iv
.5.1.1 Liferay.............................................................................................116
.5.1.2 Sakai................................................................................................116
.5.1.3 Single Sign On.................................................................................116
.5.2. Hướng phát triển.....................................................................................116
PHỤ LỤC...............................................................................................................119
A. Một số so sánh giữa Moodle và Sakai...........................................................119
B. Hiện thực UserDirectoryProvider..................................................................123

v
DANH MỤC CÁC HÌNH
Hình 1 - Khái niệm SSO.............................................................................................2
Hình 2 - Triển khai OpenSSO....................................................................................4
Hình 3 - Sơ đồ xác thực của OpenSSO.......................................................................4
Hình 4 - Sơ đồ hoạt động chung của J2EE Agent.......................................................5
Hình 5 - Sơ đồ hoạt động chi tiết với policy...............................................................6
Hình 6 - Chạy domain cần triên khai opensso............................................................8
Hình 7 - Cấu trúc thư mục user sau khi cấu hình thành công.....................................9
Hình 8 - Customize Configuration - Thông tin OpenSSO........................................10
Hình 9 - Customize Configuration - Configuration Data Store Settings...................11
Hình 10 - User Data Store Settings...........................................................................12
Hình 11 - Quản lý user và group trong OpenSSO....................................................13
Hình 12 - Quản lý user trong OpenSSO...................................................................14
Hình 13 - Thêm user vào group trong OpenSSO......................................................15
Hình 14 - Tạo Agent Profile.....................................................................................15
Hình 15 - Cấu hình Login Form URI trong OpenSSO.............................................17
Hình 16 - Cài đặt J22Agent......................................................................................19
Hình 17 - Kiến trúc thư mục Agent..........................................................................20
Hình 18 - Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS server. . .28
Hình 19 - Người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS server29
Hình 20 - CAS – Login Flow...................................................................................30
Hình 21 - CAS – Proxy Flow...................................................................................32
Hình 22 - CAS – Logout Flow.................................................................................32
Hình 23 - Mô hình triển khai Sakai - Liferay - CAS................................................33
Hình 24 - Cơ chế xác thực mà CAS hỗ trợ...............................................................35
Hình 25 - Cấu hình CAS - Liferay............................................................................42
Hình 26 - Cấu hình Liferay - LDAP.........................................................................43
Hình 27 - Cấu hình Liferay - LDAP (t.t)..................................................................43
Hình 28 - Cấu hình Liferay - LDAP (t.t)..................................................................43
Hình 29 - Cấu hình Liferay - LDAP (t.t)..................................................................44
vi
Hình 30 - Cấu hình Liferay - LDAP (t.t)..................................................................44
Hình 31 - Cấu hình Liferay - LDAP (t.t)..................................................................44
Hình 32 - Các nơi nghiên cứu và sử dụng Sakai.......................................................51
Hình 33- Quan hệ giữa các công cụ dạy và học........................................................52
Hình 34 – Sổ điểm....................................................................................................53
Hình 35 - Sakai Gradebook - Quy định cách đánh giá môn học...............................54
Hình 36 - Sakai Gradebook - Quy định cách đánh giá môn học (tt).........................55
Hình 37 - Sakai Gradebook - Quy định hệ số điểm cho bài kiểm tra/bài tập............56
Hình 38 - Quy định hệ số điểm cho bài kiểm tra/bài tập (tt).....................................56
Hình 39 - Quy định hệ số điểm cho bài kiểm tra/bài tập (tt).....................................57
Hình 40 - Sử dụng sổ điểm khi tạo bài tập................................................................58
Hình 41 - Sử dụng sổ điểm khi tạo bài kiểm tra.......................................................58
Hình 42 - Xem danh sách bài tập..............................................................................61
Hình 43 – Chấm điểm...............................................................................................62
Hình 44 - Xem danh sách bài tập theo sinh viên.......................................................63
Hình 45 - Xem bài tập dưới góc nhìn của sinh viên..................................................63
Hình 46 - Sakai Test & Quizzes - Tạo ngân hàng câu hỏi........................................65
Hình 47 - Sakai Test & Quizzes - Thêm câu hỏi......................................................65
Hình 48 - Soạn nội dung câu hỏi..............................................................................66
Hình 49 - Phản hồi đáp án cho sinh viên..................................................................66
Hình 50 - Sakai Presentations...................................................................................67
Hình 51 - Lấy sự kiện từ trang khác.........................................................................71
Hình 52 - Mô hình miền Sakai CMS........................................................................73
Hình 53 - Mô hình Simple........................................................................................73
Hình 54 - Mô hình Large Lecture.............................................................................74
Hình 55 - Tạo theme mới cho Liferay - Cấu trúc thư mục theme.............................83
Hình 56 - Portlet Tìm kiếm nhanh thời khóa biểu....................................................86
Hình 57 - Sơ đồ khái quát về hệ thống người dùng của WebSite.............................94
Hình 58 - Quy trình tạo mẫu tin của hệ thống FIT portal.........................................95
Hình 59 - Cấu trúc trang...........................................................................................96
Hình 60 - Trang chủ.................................................................................................98
vii
Hình 61 - Trang Sơ đồ tỗ chức khoa Công Nghệ Thông Tin....................................99
Hình 62 - Trang Chương trình đào tạo.....................................................................99
Hình 63 - Cấu trúc trang cho Sinh viên..................................................................100
Hình 64 - Trang hiển thị danh sách sinh viên đại học.............................................101
Hình 65 - Trang đoàn thể........................................................................................102
Hình 66 - Trang thời khóa biểu..............................................................................103
Hình 67 - Trang tìm nhanh Thời khóa biểu............................................................104
Hình 68 - Trang Nghiên cứu...................................................................................104
Hình 69 - Trang Mẫu đơn.......................................................................................105
Hình 70 - Trang Sơ đồ trang...................................................................................106
Hình 71 - Trang Diễn đàn.......................................................................................106
Hình 72 - Trang thêm thời khóa biểu......................................................................107
Hình 73 - Trang quản lý tài liệu..............................................................................108
Hình 74 - Trang quản lý hình ảnh...........................................................................108
Hình 75 - Cấu trúc trang của các Website cá nhân của giảng viên.........................109
Hình 76 - Công cụ cho giảng viên..........................................................................109
Hình 77 - Cấu trúc trang của trường Đại Học Nông Lâm.......................................110
Hình 78 - Cách tạo Website đơn vị.........................................................................112
Hình 79 - Cấu trúc trang của Template For Web....................................................112
Hình 80 - Export một Organizations.......................................................................113
Hình 81 - Tạo mới 1 tổ chức...................................................................................113
Hình 82 - Danh mục Website của khoa..................................................................114
Hình 83 - Danh mục Website của Phòng Ban........................................................115
Hình 84 - Danh mục Website của Trung tâm.........................................................115
Hình 85 - Hoạt động hàng tuần...............................................................................121
Hình 86 - Moodle - Các loại câu hỏi......................................................................122
Hình 87 - Cây thư mục providers...........................................................................124

viii
TÓM TẮT
• Tên đề tài: Tìm hiểu và triển khai hệ thống đăng nhập một lần cho cổng
thông tin dịch vụ. Tìm hiểu, đánh giá và triển khai hệ thống học trực tuyến E-
learning.

• Thời gian thực hiện:

− Ngày được giao đề tài: 10-02-2009

− Ngày hoàn tất đề tài: 25-09-2009

• Nội dung nghiên cứu:

− Tìm hiểu portal mã nguồn mở Liferay.

− Tìm hiểu hệ thống học trực tuyến (E-learning) Sakai.

− Tìm hiểu cơ chế đăng nhập một lần (Single Sign On) với hai sản phẩm là
OpenSSO và CAS.

− Xây dựng portal cho khoa Công Nghệ Thông Tin – Đại Học Nông Lâm
bằng Liferay portal kết hợp với hệ thống học trực tuyến Sakai, sử dụng cơ
chế Single Sign On.

• Kết quả chủ yếu đã đạt được:

− Nắm vững cơ chế hoạt động của Liferay.

− Tìm hiểu và sử dụng các chức năng hỗ trợ học và giảng dạy của hệ thống
Sakai. Hiện thực lại hệ thống CMS và viết tool cho Sakai.

− Nắm cơ chế hoạt động của OpenSSO và CAS. Áp dụng trên các ứng dụng
đưa vào Liferay.

− Xây dựng hoàn tất cổng thông tin cho khoa Công Nghệ Thông Tin - Đại
Học Nông Lâm TPHCM, dựa trên cổng thông tin Liferay.
ix
TỔNG QUAN
Đặt vấn đề: Nhu cầu tìm kiếm thông tin từ Internet ngày càng nhiều. Cổng thông
tin là một trong những nguồn cung cấp thông tin đang được áp dụng rộng rãi trên
toàn thế giới. Khuynh hướng các dịch vụ cùng nhau chia sẽ dữ liệu người dùng đang
là hướng phát triển chung của công nghệ thông tin. Do vậy nhu cầu đăng nhập một
lần cho các dịch vụ này là không thể thiếu. Bên cạnh đó, do sức mạnh của Internet
được ứng dụng rộng rãi, công tác giáo dục đang dần thoát khỏi sự phụ thuộc về
không gian. Hệ thống học trực tuyến là một bước ngoặc trong việc hỗ trợ dạy và học
thông qua mạng Internet. Trước sự phát triển đó, nhóm chúng em mong muốn được
tìm hiểu và giới thiệu phần nào về những công nghệ trên. Với những gì đã nghiên
cứu được, nhóm chúng em hy vọng sẽ được đóng góp một phần nhỏ vào công tác
phát triển khoa.

Mục đích: Tìm hiểu công nghệ portal Liferay, tiến hành xây dựng cổng thông tin
cho khoa Công Nghệ Thông Tin – Đại Học Nông Lâm Tp.HCM. Nghiên cứu kỹ
thuật Single Sign On để áp dụng đăng nhập một lần cho các dịch vụ đưa vào cổng
thông tin. Nghiên cứu hệ thống học trực tuyến Sakai, và tích hợp vào cổng thông tin
theo cơ chế Single Sign On.

1
NỘI DUNG BÁO CÁO
Chương .1 Tìm hiểu Single Sign On.

.1.1. Single Sign On.


.1.1.1 Khái niệm.
SSO còn được gọi là ESSO cho phép nhập cùng một id/password để đăng nhập
nhiều ứng dụng trong cùng một tổ chức (Enterprise).

Hình 1 - Khái niệm SSO

Ví dụ:

Người dùng sử dụng nhiều dịch vụ như: Đăng ký môn học, hê thống xem điểm, …
ứng mỗi dịch vụ chúng ta có một tài khoản riêng. Trước đây, khi chưa sử dụng SSO
thì khi với mỗi dịch vụ chúng ta đều phải nhập thông tin để xác thực. Khi một tổ
chức đã thống nhất sử dụng SSO cho tất cả các dịch vụ của họ thì người dùng chỉ
cần đăng nhập một lần duy nhất trên bất kỳ dịch vụ nào trong tổ chức, thì khi truy
xuất những dịch vụ khác, người dùng không cần phải đăng nhập lại.

.1.1.2 Lợi ích.


- Tránh việc nhớ nhiều thông tin đăng nhập (username & password) khi dùng
nhiều dịch vụ.

- Tiết kiệm thời gian khi tái lập lại mật khẩu cho một người dùng (identity user).

- Bảo mật tất cả các cấp độ của việc thoát hay truy xuất vào hệ thống.

2
- Người phát triển ứng dụng không cần phải hiểu và thực hiện nhận dạng bảo mật
trong ứng dụng của họ.

.1.1.3 Các giải pháp Single Sign On.


- Open Single Sign-On (OpenSSO) hoạt đông dựa trên Token.

- Central Authenticate Service (CAS) hoạt đông dựa trên Ticket.

- Java Open Single Sign On ( JOSSO).

.1.2. Open Single Sign On Enterprise.


.1.2.1 Giới thiệu.
.1.2.1.1 OpenSSO Enterprise là gì?
- OpenSSO là một sản phẩm open source của SUN. Nó là một sản phẩm đơn lẽ,
kết hợp các tính năng của Sun Java System. Access Manager, Sun Java System
Fedearation Manager và Sun System SAML v2 Java Plugin.

- Lịch sử phát triển.

o 2001 – iPlanet Directory Server Access Management Edition 5.0.


o 2005 – OpenSSO project được chú ý đến.
o 2006 – OpenSSO công bố source code.
o 2007 – Sun Java System Access Manager 7.1 đưa ra bản “close source”
cuối cùng cho OpenSSO.
o 2008 – Sun OpenSSO Enterprise 8.0 bản open source đầu tiên hỗ trợ đầy
đủ các chức năng của OpenSSO.
- Các phiên bản của OpenSSO.

o OpenSSO Express: Được công bố vào 7/2008, cập nhật ba tháng một lần.

o OpenSSO Enterprise: 9/2008 Sun phát triển bản Enterprise, 11/2008 ra


bản OpenSSO Enterprise 8.0, 12->15 tháng sẽ cho ra một phiên bản mới.

.1.2.1.2 Các tính năng của OpenSSO Enterprise.


- Access Control.

- Federation Management.

- Web Service Sercurity.

- Indentity Web Service.

3
.1.2.1.3 OpenSSO Enterprise làm việc như thế nào?
Khi truy cập vào những tài nguyên được bảo vệ, request cần được xác thực và phải
có đủ quyền truy cập. Khi một người gởi Http request để truy cập tài nguyên được
bảo vệ, policy agent chặn request này và kiểm tra. Nếu OpenSSO token được tìm
thấy mà không hợp lệ, policy agent sẽ yêu cầu server tiến hành xác thực và cấp
phép.

Hình 2 - Triển khai OpenSSO

- Workflow giải thích sự tương tác giữa các thành phần.

Hình 3 - Sơ đồ xác thực của OpenSSO

.1.2.1.4 Policy Agent.


Khái niệm.

Policy agent là web application hay chương trình với nhiệm vụ ngăn tất cả request
đến ứng dụng, để kiểm tra xem người dùng đã xác thực hay chưa.

4
Hình 4 - Sơ đồ hoạt động chung của J2EE Agent

- 1. Từ trình duyệt, người dùng kết nối đến ứng dụng web.

- 2. Policy Agent sẽ kiểm tra token có tồn tại trong URL hay không? Nếu token
chưa tồn tại thì Policy Agent sẽ chuyển browser đến OpenSSO Server.

- 3. OpenSSO Server xác thực người dùng thông qua login form. Người dùng nhập
Username / Password để xác thực.

- 4. Opensso activate login session (tức là tạo ra session cho người dùng và kích
hoạt nó nếu xác thực thành công).

- 5. Opensso gởi token cho browser (browser sẽ lưu token dưới dạng cookie) và
Browser sẽ gởi token đến cho Agent.

- 6. Policy Agent sẽ lấy thông tin token gởi đến OpenSSO server để kiểm tra.

- 7. OpenSSO sẽ gởi thông tin login (username, password) và thông tin


authorization (role) đến Agent nếu kiểm tra token hợp lệ.

- 8. Policy Agent cho phép truy cập ứng dụng hay không và ghi thông tin session
trên URL.

5
Hình 5 - Sơ đồ hoạt động chi tiết với policy

.1.2.2 Triển Khai.


.1.2.2.1 Triển khai OpenSSO trên Server.
Trên GlassFish v2

Yêu cầu
• Đã cài đặt GlassFish và tạo domain để triên khai opensso (trong trường hợp
này sử dụng domain mặc định domain1 cho opensso, có thể tạo domain
khác).

• Sau đó thay đổi một vài thuộc tính trong. file


../glassfish/domains/domain1/config/domain.xml của domain1 như sau:

o Tìm đến thẻ <jvm-options>

6
 Thay đổi giá trị “-client” bởi “-server”

 Thay đổi giá trị “-Xmx512m” bởi “-Xmx1024m”

o Save và hoàn tất.

• Download opensso enterprise bản mới nhất và giải nén vào thư mục chỉ định.
(ví dụ: c:/opensso). File opensso.war nằm trong thư mục
c:/opensso/deployable-war dùng để triển khai.

• Tạo FQDN (Full Qualified Domain Name) để chuẩn bị cho bước cấu hình :

o FQDN = hostname + domain name. Domain Name = Name + phần


mở rộng (ví dụ: cntt.vn, cntt.com, cntt.org….).

o Vào thư mục C:/Windows/System32/Drivers/etc/ và mở file hosts


thêm vào tên domain đầy đủ và lưu lại.

 Ví dụ: 127.0.0.1 localhost nonglam.cntt.com

Lúc này đã tạo ra một tên domain đầy đủ, bây giờ chạy tất cả các ứng
dụng trên máy với địa chỉ http://nonglam.cntt.com:port/name_app. Ví
dụ, để vào trang chủ của domain1 với địa chỉ:
http://nonglam.cntt.com:4848 thay cho http://localhost:4848.

o Chú ý: full domain name có ít nhất hai dấu chấm trở lên. Ví dụ
(nonglam.cntt là không hợp lệ bới vì chưa có hostname).

Triển khai
• Chạy domain cần triên khai opensso (đang ví dụ domain1) với lệnh “start-
domain domain1”:

7
Hình 6 - Chạy domain cần triên khai opensso

• Vào trang chủ của domain1 http://nonglam.cntt.com:4848 và Login vào với


tài khoản admin/adminadmin.

• Sau đó chọn tab “Web application” sau đó chọn deploy bên tay phải và trỏ
đến file opensso.war trong thư mục c:/opensso/deployable-war/ .

• Sau deploy xong, chạy ứng dụng OpenSSO bằng cách nhấn vào link lunch
hay vào trực tiếp địa chỉ: http://nonglam.cntt.com:8080/opensso. Sau đó đến
phần cấu hình OpenSSO cho lần chạy đầu tiên.

Chú ý: Có một cách deploy trực tiếp khác rất đơn giản: chỉ cần chep file
opensso.war vào thư mục ../domain1/autodeploy và sau đó chạy lại server.

Trên Tomcat

Yêu cầu
• Đã cài đặt tomcat

• Xác định cổng chạy server, bằng cách vào thư mục config.

Triển khai
• Cách đơn giản: Copy file opensso.war vào thư mục

c:/apache-tomat-6.0.18/webapp. Sau đó chạy lại server.

• Cách khác: Sử dụng trang chủ của Tomcat để triển khai ứng dụng.

8
.1.2.2.2 Cấu hình mặc định cho OpenSSO (chạy lần đầu tiên).
Chạy opensso với địa chỉ http://nonglam.cntt.com:8080/opensso (có thể sử dụng
cổng khác cho opensso). Vì đây là lần chạy đầu tiên nên nó cần cấu hình ban đầu để
lưu những thông tin cần thiết.

Default Configuration

• User mặc định là: amAdmin

• Cần nhập thông tin mặc định như password của user admin.

(VD: password là “adminadmin”).

• Xuất hiện màn hình báo thành công và click “Process to login” để bắt đầu
đăng nhập vào Opensso với user/password: amadmin/adminadmin.

• Chú ý: Sau khi cấu hình mặc định thành công, nó sẽ tạo ra các thư mục
“opensso”, và “.openssocfg” trong user của Window, ví dụ
“C:\Users\QuocTan”.

Hình 7 - Cấu trúc thư mục user sau khi cấu hình thành công

Khi gặp sự cố, chỉ cần xóa tất cả các thự mục này và chạy lại ứng dụng opensso để
cấu hình lại.

Customize Configuration

• Trên trang Default User Password, nhập vào password và confirm password
cho Amadmin user. Nhấn Next để tiếp tục.

• Trên trang Server Settings, đặc tả thông tin của OpenSSO Enterprise.

9
Hình 8 - Customize Configuration - Thông tin OpenSSO

o Server URL: Là host của server (nơi mà triển khai opensso), nó có thể
là một trong những giá trị sau:

 localhost

 FQDN (Full qualified domain name). Ví dụ:


http://nonglam.cntt.com:8080

o Cookie Domain: Là tên của DNS domain, cái mà OpenSSO trả về cho
Browser khi nó authenticate xong và gán token SSO cho user.

o Platform Locale: Là ngôn ngữ mặc định cho OpenSSO. Mặc định là
en_US (US English). Một vài giá trị khác như: de(German),
es(Spanish), fr(french), ja(Japanese)…

o Configuration Directory: Là vị trí thư mục để lưu thông tin cấu hình
của OpenSSO Enterprise. Nhấn Next để tiếp tục.

• Configuration Data Store Settings: Kiểm tra xem, nếu đây là lần cấu hình đầu
tiên thì chọn First Instance. Ngược lại, có một hoặc nhiều OpenSSO thì cho Add
to Existing Deployment và nhập vào Server URL của lần cấu hình đầu tiên.

10
Hình 9 - Customize Configuration - Configuration Data Store Settings

• Configuration Store Detail.

o Configration Data Store:

 OpenSSO: Lưu trữ dữ liệu cấu hình của opensso dưới thư mục
configuration_directory/opends trên local server.

 Sun Java System Directory Server: Lưu trữ thông tin cấu hình
trên Sun Java System Directory Server.

o SSL Enable: sử dụng sử dụng giao thức LDAPs để kết nối đến
Directory Server.

o Host name: Là tên host của Directory Server.

o Port: Cổng của Directory Server. Mặc định là 50389.

o Root Suffix: Là Directory Server khởi tạo ban đầu.

• User Data Store Settings.

o OpenSSO User Data Store: Lưu trữ dữ liệu người dùng trong
OpenSSO user data store.

Chú ý: Lưu trữ thông tin người dùng trong OpenSSO User Data Store
được sử dụng đối với lượng người dùng nhỏ.

o Other User Data Store: Lưu trữ dữ liệu người dùng trong một data
store như: Sun Java System Directory Server, Microsoft Active
Directory hoặc IDM Tivoli Directory Server.
11
Multiple OpenSSO Enterprise Instance: nếu cấu hình nhiều OpenSSO
để sử dụng cùng một Directory Server như user data store. Tham khảo
Install Sun Java System Directory Server and Creating Instance for
Sun OpenSSO Enterprise User Data.

Hình 10 - User Data Store Settings

o User Store Detail.

 SSL Enable: Cho phép SSL security.

 Directory Server Name: Tên của Directory Server.

 Port: Cổng của Directory Server. Mặt định là 389.

 Root Suffix: tên đường dẫn của thư mục gốc

 Login ID: Là admin của directory server.

 Passoword: Mật khẩu của admin trong directory server.

 User Data Store Type:

• LDAP with OpenSSO Schema: Directory Server phải có


OpenSSO Schema Loaded.

• Generic LDAP: Directory Server khộng co OpenSSO


Schema loaded.
12
Nhấn Next để tiếp tục

• Site configuration: Chọn No. Nhấn Next để tiếp tục.

• Chỉ định password cho policy agent. Nhấn Next để tiếp tục.

• Xem lại summary detail và nhấn Create configuration.

.1.2.3 Tạo user và group trong OpenSSO.


Muốn cấu hình trong OpenSSO, ta phải login vào OpenSSO với quyền
Admin. Chọn Access ControlReal NameSubject (thẻ này sẽ quản lý user
và group).

Hình 11 - Quản lý user và group trong OpenSSO

.1.2.3.1 Tạo user.


• Trong thẻ con User, chọn New để tạo user mới. Điền đầy đủ thông tin cho
user. Chọn OK hoàn tất tạo user (đánh dấu chọn vào active để kích hoạt user).

• Quay lại tab user hiển thị tất cả user hiện có. Sau đó nhấn vào user vừa tạo để
xem chi tiết và những tab con:

13
Hình 12 - Quản lý user trong OpenSSO

o General: Hiển thị thông tin về user và cho phép chỉnh sửa thông
tin.

o Group: Cho phép user chọn group để gia nhập.

.1.2.3.2 Tạo group.


• Từ tab Subject, chọn tab con Group. Sau đó chọn New để tạo group mới. Và
điền ID của Group và nhấn OK để hoàn tất.

• Nhấn vào tên group để và trang hiệu chỉnh group.

o General: Hiển thi thông tin của group (thông tin này sẽ được sử dụng
đế cấu hình cho ứng dụng, cụ thể là gán role cho group trong file sun-
xml).

o User: Cho phép thêm user vào group. Chọn user và nhấn Add để thêm
user vào group. Nhấn Save để lưu lại thông tin.

14
Hình 13 - Thêm user vào group trong OpenSSO

.1.2.4 Tạo Agent Profile Trong OpenSSO.


.1.2.4.1 Giới thiệu Agent Profile.
• Agent Profile lưu những thông tin về Agent.

• Thông tin này được opensso quản lý, để nhận biết Agent.

.1.2.4.2 Tạo Agent Profile.


• Trước hết, đăng nhập vào opensso admin. Và chọn tab Access Control 
Nhấn RealName  Agent  J2EE New.

Hình 14 - Tạo Agent Profile


15
Điền đầy đủ thông tin các trường sau:

o Name: Tên của agent (nhớ tên này để sau đó cài đặt Agent trên web
server chứa các application).

o Password: Mật khẩu của agent (hãy lưu lại mật khẩu thành một file
text để chuẩn bi cài đặt Agent.Vi dụ: password.txt).

o Configuaration: Chọn Centralized (cho phép bạn chỉnh sửa thông tin
agent bằng giao diện). Nếu chọn Local, bạn không thể quản lý agent
bằng giao diện trong opensso admin (phải dùng lệnh).

o Server URL: Là địa chỉ của OpenSSO đã triển khai. Ví dụ:


http://nonglam.cntt.com:8080/opensso

o Agent URL: Là địa chỉ của Agent dự định sẽ cài đặt sau phần cấu hình
này. Ví dụ: Ta sẽ cài đặt Agent trong domain đã tạo ở trên :

Tên domain mydomain


Tên user admin (user) Quoctan
Pass (it nhất 8 ký tự) 12345678
Cổng admin (addminport) 5050
Cổng chạy ứng dụng (instanceport) 8888

Địa chỉ agent là : http://nonglam.cntt.com:8888/agentapp

Ứng dụng agentapp là một ứng dụng web, sẽ triển khai lên domain này
sau khi cài đặt agent.

o Nhấn Create để tạo agent.

.1.2.4.3 Cấu hình Agent Bảo Vệ J2EE Application.


• Một vài chú ý khi cài đặt.

o Vào agent profile và opensso đã tạo để cấu hình agent. Access


ControlReal NameAgent J2EE tab Agent Name.

o Những thuộc thuộc tính nếu có ghi “Hot-swap:no” thì khi cấu
hình xong, bắt buộc phải chạy lại container (web server chứa agent).
16
• Đăng nhập vào Opensso với quyền amadmin. Vào Access
ControlReal NameAgent J2EE tab Agent Name.

• Chọn Global tab và thiết lập những thông tin như sau:

o Nhấn General và tìm đến thuộc tính Agent Filter Mode: Xóa hết
những giá trị có sẵn. Sau đó thêm “J2EE_POLICY” vào trường
“Coressponding Map Value”.

o Chú ý chọn Save để lưu kết quả.

o Đến thuộc tính Agent Debug Level: Đánh dấu chọn vào “message” và
chọn Save để lưu.

• Nếu ứng dụng đã tồn tại web-tier security thì thêm phần cấu hình sau: Thêm
giá trị vào thuộc tính Login Form URI (giá trị này được cấu hình trong
web.xml của ứng dụng với thẻ “Form-Login-Page” ).

Hình 15 - Cấu hình Login Form URI trong OpenSSO

.1.2.5 Cài đặt Policy Agent 3.0


• Theo như mô hình, Opensso được cài đặt ở một server và OpenSSO Policy
Agent cài đặt chung server với những ứng dụng mà nó bảo vệ.

Ví dụ: application server sử dụng là Galssfishv2

Cài đặt Opensso tại domain1 chạy trên cổng 8080:


http://nonglam.cntt.com:8080/opensso. Tham khảo ở trên.

Cài đặt Policy Aagent tại mydomain và chạy trên cổng 8888:
http://nonglam.cntt.com:8888/agentapp
17
• Chú ý: Agent và Opensso bắt buôc phải khác server (nếu sử dụng Glassfish
thì phải khác domain).

.1.2.5.1 Trên GlassFish.


Yêu cầu chuẩn bị

• Tải J2EE Agent tương ứng cho Glassfishv2

• Giải nén ra thư mục chỉ định. Ví dụ: C:/myagent

• Cần tạo file chứa password (ví dụ: c:/myagent/password.txt) và password này
phải giống với password đã lưu trong Agen Profile. (ví dụ: adminadmin)

• Nếu chưa có domain, thì hãy tạo domain để cài đặt Agent len domain này.
Ngược lại, chọn domain để cài đặt agent (ví dụ: myagent) và nhớ đường dẫn
đến thư mục config của domain (c:/glassfish/domains/myagent/config) để
chuẩn bị cho việc cài đặt.

• Nhớ địa chỉ Server URL của OpenSSO và Agent URL trong Agent Profile.

Chú ý: Chạy server chứa Opensso (ở đây là domain1) trước khi cài đặt Agent.

Cài đặt

• Vào CMD và di chuyển đến thư mục bin của J22Agent. C:/myagent/j2ee-
agents/ appserver_v9_agent/bin và gõ lệnh agentadmin –install để bắt đầu.

• Điền đầy đủ thông tin cho các trường như sau:

18
Hình 16 - Cài đặt J22Agent

o Application server config directory path: Đường dẫn đến thư mục
config của Domain mà bạn đã chọn để cài đặt agent.

o OpenSSO server URL: Địa chỉ của Opensso đã triển khai.

o AgentURL: Địa chỉ của Agent (cụ thể là của ứng dụng
agentapp) mà ta dự định triển khai.

o Enter agent profile name: Đây là tên agent profile. Tên này đã
được tạo trong phần Agent Profile trong OpenSSO console.

o Enter the path to password file: Đường dẫn đến file chứa
password (trong phần yêu cầu đã tạo).

• Sau đó chọn [1] (mặc định) để tiếp tục phần cài đặt và hoàn tất.

.1.2.5.2 Sử dụng Policy Agent 3.0


Kiến trúc thư mục Agent.

19
Hình 17 - Kiến trúc thư mục Agent

• Một số thông tin về các thư mục trong Agent.

o Agentxxx (trong trường hợp này là Agent001): Nó sẽ được tạo ra khi


cài đặt agent thành công, đây là agent đã được cài đặt chứa thông cấu
hình agent, nếu cài tiếp thì sẽ tự động tăng lên Agent002.

o Bin: Chứa tập tin thực thi .bat . Cụ thể là agentadmin.bat

o Etc: Chứa file triển khai agentapp.war, nó sẽ được triển khai lên web
server (nơi mà agent được cài đặt) sau khi cài đặt Agent.

o Sampleapp: Chứa source code và file triển khai của agentsample.ear.


Đây là ví dụ mẫu để làm quen với agent.

Sử dụng

• Sau đây là một số lệnh thường sử dụng trong Agent. Để sử dụng lệnh của
Agent phải chuyển đến thư mục bin của Agent.

o Cài đặt Agent: agentadmin - - install

o Xóa Agent: agentadmin - - uninstall

o Xem danh sách agent: agentadmin –listAgents

o Xem thông tin Agent: agentadmin

20
.1.2.6 Bảo vệ ứng dụng Java EE Application với OpenSSO Policy
Agents.
.1.2.6.1 Giới thiệu.
• Khi triển khai ứng dụng, trước hết phải xem xét là triển khai trên web
container nào. Vì mỗi web container sẽ có yêu cầu cấu hình khác nhau cho
mỗi ứng dụng về bảo mật.

• Một số cấu hình khác nhau như về phân quyền hay kết nối CSDL người
dùng.

• Một ứng dụng khi triển khai thường có hai trường hợp xảy ra:

o Ứng dụng đã tồn tại các cấu hình về security, đã khai báo trong file
web.xml, vì thế việc cấu hình làm sao để Agent hiểu ứng dụng đã tồn
tại chính sách bảo mật theo chuẩn J2EE.

o Ứng dụng không có chế độ mật, thì lúc này việc cấu hình chính sách
bảo mật cho ứng dụng sẽ làm toàn bộ trên Agent.

.1.2.6.2 Yêu Cầu.


• Môt ứng dụng theo chuẩn J2EE muốn agent bảo vệ thì trong file web.xml
phải khai báo Agent Filter của J2EE Agent trong web.xml của ứng dụng.
Chép và dán đoạn khai báo sau vào web.xml của ứng dụng

<filter>
<filter-name>Agent</filter-name>
<filter-class>
com.sun.identity.agents.filter.AmAgentFilter
</filter-class>
</filter>

<filter-mapping>
<filter-name>Agent</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>

• Nếu Web app đã cấu hình chính sách bảo mật trong file web.xml, và để
Agent hiểu thì bắt buộc trong file web.xml phải khai báo phương thức xác
thực là FORM.

21
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login/Login.jsp</form-login-page>
<form-error-page>/login/LoginError.jsp</form-error-page>
</form-login-config>
</login-config>

• Chú ý : cấu hình Agent Mode Filter là J2EE_POLICY để Agent hiểu được
Java EE Application.

.1.3. Central Authenticate Service (CAS).


.1.3.1 Giới thiệu.
.1.3.1.1 CAS là gì?
- Là một giải pháp Single Sign On, mã nguồn mở được phát triển bởi đại hoc
Yale.

- Hỗ trợ nhiều thư viện phía client được viết bởi nhiều ngôn ngữ: PHP, Java,
PL/SQL, …

- CAS lấy thông tin Single Sign On thông qua cookie. Cookie này sẽ bị hủy khi
user đăng xuất khỏi CAS hoặc đóng trình duyệt. Cookie được sinh ra bởi CAS,
còn được gọi là TGT Cookie (Ticket Granting Cookie) chứa một id duy nhất và
thời gian hết hạn. Thời gian hết hạn là 8 giờ.

- CAS cung cấp nhiều trình quản lý xác thực (authenticate handler) khác nhau.
CAS xác thực nhiều loại thông tin người dùng như username/password, X509
Certificate, ...để xác thực những thông tin người dùng khác nhau này, CAS sử
dụng những trình quản lý xác thực tương ứng.

- CAS còn cung cấp tính năng “Remember Me”. Developer có thể cấu hình tính
năng này trong nhiều file cấu hình khác nhau và khi người dùng chọn
“Remember me” trên khung đăng nhập, thì thông tin đăng nhập sẽ được ghi nhớ
với thời gian được cấu hình (mặc định là 3 tháng) và khi người dùng mở trình
duyệt thì CAS sẽ chuyển đế service url tương ứng mà không cần hiển thị khung
đăng nhập.

.1.3.1.2 Các phiên bản của CAS.


• CAS 1.0

- Được tạo bởi Yale University, khởi đầu từ năm 1999.

- Là một Web Single Sign On, dễ sử dụng.

• CAS 2.0
22
- Cũng được tạo ra bởi Yale University.

- Giới thiệu thêm tính năng mới là Proxy Authentication.

• JA-SIG CAS 3.0

- Trở thành JA-SIG project vào 2004.

- Mục đích là làm cho CAS tương thích cao hơn, mềm dẻo hơn.

- 100% tương thích với CAS 2.0

.1.3.1.3 CAS URIs.


CAS thực hiện Single Sign On thông qua những URI và sinh ra những ticket khác
nhau. CAS sẽ sử dụng những URI sau:

- /logout

o Hủy Single Sign On session và ticket granting cookie

o Hiển thị một trang trạng thái để báo với user đã đăng xuất.

Tham số “url” có thể được chỉ định đến /logout và nếu được chỉ định,
“url” sẽ được hiển thị trong trang logout cùng với thông báo đăng xuất.

- /validate

o Kiểm tra tính hợp lệ của service. CAS làm service ticket có hiệu lực,
service ticket được sinh ra từ thông tin xác thực lấy từ request.

o Những tham số sau có thể chỉ định đến /validate URI

 Service (bắt buộc)

 Ticket (bắt buộc) – service ticket được sinh ra bởi /login

 Renew (không bắt buộc) – nếu tham số này được thiết lập.

 Ptgurl – url của proxy callback

- /serviceValidate sẽ trả về một xml-formatted response. Khi thành công, response
chứa username và proxy-granting ticket. Khi thất bại, response chứa một mã lỗi
với thông điệp thất bại tương ứng. Sau đây là một số mã lỗi được trả về response
nếu /serviceValidate thất bại.

o INVALID_REQUEST: Không tìm thấy tham số cần tìm trong request.

23
o INVALID_TICKET: Ticket được cung cấp không hợp lệ hoặc ticket
không đến từ login và “renew” được thiết lập trên validation.

o INVALID_SERVICE: Ticket được cung cấp không hợp lệ nhưng service
được chỉ định không khớp với service mà liên kết với ticket.

o INTERNAL_ERROR: Lỗi cục bộ xuất hiện trong khi kiểm tra tinh hợp lệ
của ticket.

- /proxyValidate làm việc giống như /serviceValidate, ngoại trừ nó làm cho proxy
ticket có hiệu lực. Những tham số và mã lỗi giống tương tự. Khi thành công,
respone chứa PGT và danh sách các proxy cá mà việc xác thực được thực thi.
Những proxy được viếng thăm gần nhất sẽ nằm trên đỉnh, và ngược lại

- /proxy

o Cung cấp proxy ticket đến những service, lấy PTG thông qua
/proxyValidate hoặc /serviceValidate

o Những tham số sau được yêu cầu cho /proxy URI

 Pgt – proxy granting ticket

 TargetService – service identifier của back-end service. Service


identifier phải khớp với service identifier được chỉ định đến
/proxyValidate nhờ vào sự hợp lệ của proxy ticket.

o /proxy sẽ trả về xml-formatted service response. Thành công, response sẽ
chứa đựng proxy ticket. Thất bại, response chứa đựng mã lỗi với thông
điệp tương ứng. Các mã lỗi sẽ được trả về trong /proxy:
INVALID_REQUEST, BAD_PGT, INTERNAL_ERROR. BAD_PGT có
nghĩa là pgt không hợp lệ.

- /samlValidate

o SAML (Secuirty Assertion Markup Language) framework.

URI Mô tả
/login Hiển thị khung đăng nhập yêu cầu người dùng xác
thực
/logout Hủy Single Sign On session và ticket granting cookie
/validate Kiểm tra tính hợp lệ của Service Ticket. Nếu nó

24
không sử dụng proxy authentication
/serviceValidate Kiểm tra tính hợp lệ của Service Ticket và trả vể một
XML-fragment và sinh ra proxy-granting ticket khi
được yêu cầu
/proxyValidate Thực thi giống như /serviceValidate và ngoài ra còn
kiểm tra tính hợp của proxy ticket
/proxy Cung cấp Proxy Ticket đến service
/samlValidate
/services/add.html Một tính năng admin. Thêm những service đến danh
sách Registered Services.
/services/edit.html Chỉnh sửa những service đã đăng ký
/services/manage.html Quản lý những service đã đăng ký như: thêm, xóa,
sửa.
/services/logout.html Đăng xuất từ trang admin service
/services Xóa service bởi tham số “id” được cung cấp

/deleteRegisteredService.html

.1.3.1.4 CAS Tickets.


Ticket đơn giản là một chuỗi ký tự ngẫu nhiên và bắt đầu với một tiền tố như
(ST-,TGC-,…) và nó là id duy nhất cho một thao tác nào đó.
Trong quá trình xác thực của CAS, một số ticket được tạo ra với mục đích lưu trữ
thông tin và bảo mật. Sau đây là khái niệm một số ticket được sử dụng trong CAS.

Ticket-Granting Ticket (TGT).

- Là một chuỗi ký tự chứa dữ liệu bảo mật ngẫu nhiên và bắt đầu bằng “TGT”,
chứa id duy nhất và thời gian hết hạn.

- TGT được tạo ra CAS Server xác thực thành công.

- Không có TGT, user của CAS không thể Single Sign On

- TGT sẽ được thêm vào HTTP Cookie (cở sở để Single Sign On) và nó sẽ được
kiểm tra khi truy cập ứng dụng.

Ví dụ: TGT sẽ được lưu xuống browser là TGC (Ticket Granting Cookie) là một
HTTP Cookie của CAS. Cookie này duy trì trạng thái đăng nhập cho client. Khi
25
client chuyển đến các ứng dụng khác, cookie này sẽ được kiểm tra đế tự động
đăng nhập cho user. TGC sẽ bị hủy khi đóng trình duyệt hay client chọn logout
từ ứng dụng. Giá trị của TGC bắt đầu bằng “TGC-“.

Service Ticket (ST).

- Service Ticket sẽ được tạo ra khi CAS Url có chứa tham số service và thông tin
xác thực được truyền đến và xác thực thành công.

Ví dụ: https://server/CAS/login?service=http%3A%2F%2Fwww.service.com

- Mỗi Service chỉ có một service ticket duy nhất và được sử dụng một lần duy
nhất.

- ST là một chuỗi ký tự, được sử dụng bởi client như là thông tin xác thực để truy
cập đến dịch vụ.

- Service ticket phải bắt đầu với ký tự “ST-“.

Ví dụ: ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7

Proxy Ticket (PT).

- CAS Proxy là một service muốn truy xuất những service khác thay mặt cho một
user riêng biệt. Proxy Ticket (PT) được sinh ra từ CAS nhờ vào một service thể
hiện của một Proxy Granting Ticket hợp lệ và một service identifier (giá trị của
tham số “url” của /proxy url) cho back-end service đến cái nó kết nối.

- Proxy Ticket là một chuỗi ký tự ngẫu nhiên mà một service sử dụng như thông
tin đăng nhập để truy cập vào một back-end service thay mặt cho client.

- Proxy ticket chỉ hợp lệ cho service identifier được chỉ định đến /proxy url khi
chúng được sinh ra.

- Proxy ticket bắt đầu bằng “PT”.

Proxy-Granting Ticket (PGT).

- PGT được lấy từ CAS nhờ vào sự hợp lệ của service ticket hoặc proxy ticket.
Nếu một service mong muốn proxy xác thực client đến một back-end service, nó
yêu cầu một proxy-granting ticket.

Proxy-Granting Ticket IOU.

Trên một ticket hợp lệ, một service có thể yêu cầu một proxy ticket. Trong CAS
2.0, cách chúng ta xác thực service được yêu cầu để gởi PGT, PGTIOU đến

26
proxy callback url được chỉ định như một request parameter. Proxy callback url
phải chạy thông qua kênh bảo mật. Chúng ta xác minh certificate của nó. Sau đó,
trả về trong ticket hợp lệ, phản hồi TGTIOU. Từ response này, service sẽ rút
TGTIOU và sử dụng nó để tìm TGT từ bộ nhớ.

Login Ticket.

- Là một chuỗi ký tự, được sinh ra bởi /login, là một thông tin đăng nhập và được
đưa đến /login.

- Mục đích là ngăn cản sử phản hồi lại thông tin xác thực.

- Login ticket được sinh ra bởi /login, phải là duy nhất và bắt đầu với “LT-”.

.1.3.1.5 Nguyên tắc hoạt động của CAS.


Chứng thực người dùng với CAS server.

- Người dùng nhập UserId / Password vào khung đăng nhập. Các thông tin này
được truyền cho CAS server thông qua giao thức HTTPS là một giao thức bảo
đảm dữ liệu được mã hóa trước truyền đi.

- Xác thực thành công, TGC được sinh ra và thêm vào trình duyệt dưới hình thức
là cookie.TGC này sẽ được sử dụng để Single Sign On với tất cả các ứng dụng

Truy cập vào ứng dụng.

- Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS server.

o Người dùng truy xuất ứng dụng thông qua trình duyệt.

o Ứng dụng lấy TGC từ trình duyệt và chuyển nó cho CAS server thông qua
giao thức HTTPS.

o Nếu TGC này là hợp lệ, CAS server trả về một Service Ticket cho trình
duyệt, trình duyệt truyền ST vừa nhận cho ứng dụng.

o Ứng dụng sử dụng ST nhận được từ trình duyệt và sau đó chuyển nó cho
CAS server.

o CAS server sẽ trả về ID của người dùng cho ứng dụng, mục đích là để
thông báo với ứng dụng người dùng này đã được chứng thực bởi CAS
server.

o Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng.

27
Hình 18 - Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS server

- Người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS server.

o Người dùng truy xuất ứng dụng thông qua trình duyệt. Vì chưa nhận được
TGC nên ứng dụng sẽ chuyển hướng người dùng cho CAS server.

o Người dùng cung cấp UserId / Password của mình thông qua khung đăng
nhập để CAS xác thực. Thông tin được truyền đi thông qua giao thức
HTTPS.

o Xác thực thành công, CAS server sẽ trả về cho trình duyệt đồng thời TGC
và ST.

o Ứng dụng sẽ giữ lại TGC để sử dụng cho các ứng dụng khác (nếu có) và
truyền ST cho ứng dụng.

o Ứng dụng chuyển ST cho CAS server và nhận về ID của người dùng.

o Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng.

28
Hình 19 - Người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS server

.1.3.1.6 CAS Architecture.


Login Flow.

29
Hình 20 - CAS – Login Flow

- Người dùng có thể truy xuất thông qua nhiều URI khác nhau. URI chủ yếu
là /login. Khi người dùng nhập địa chỉ http://server/CAS/login từ trình duyệt,
CAS sẽ kiểm tra Ticket granting cookie (TGC) đã tồn tại chưa. Nếu TGC đã
tồn tại, thì nó sẽ kiểm tra thời gian hết hạn của cookie và nếu còn thời hạn thì
Service Ticket (ST) sẽ được sinh ra. Nếu TGC không tồn tại hay đã hết hạn
thì CAS sẽ buộc người dùng nhập thông tin đăng nhập vào khung đăng nhập.

30
- Người dùng nhập thông tin đăng nhập và chọn Submit, CAS sẽ lấy danh sách
AuthenticationHanders từ deployerConfigContext.xml và kiểm tra xem nó hỗ
trợ AuthenticationHander nào. Nó sẽ đưa thông tin đăng nhập cho
AuthenticationHander mà nó hỗ trợ và kiểm tra thông tin đăng nhập của
người dùng. Nếu người dùng xác thực không hợp lệ sẽ được chuyển đến
khung đăng nhập để đăng nhập lại. Nếu người dùng hợp lệ thì một Ticket-
granting Ticket (TGT) sẽ được sinh ra và thêm vào cookie.

- CAS tạo ra một Service Ticket (ST) và thêm Service Ticket này đến Ticket
Registry. CAS kiểm tra có hay không service parameter thông qua /login
URL.

Ví dụ: https://server/CAS/login?service=http://www.findtechies.com/auth.jsp

- CAS gọi Service Identifier với ticket là tham số, giá trị là service ticket (st).
Các client có trách nhiệm gọi /serviceValidate URI của CAS để kiểm tra
service và service ticket. /serviceValidate sẽ được gọi bởi filter của client

Service param name: service

Service Identifier value: https://www.servertechies.com/auth.jsp

Ticket param name: ticket

Service Ticket value: ST-1856339-aA5Yuvrxzpv8Tau1cYQ7

Proxy param name: pgtUrl

Proxy-granting Url value: https://server/test.jsp

Proxy Flow

31
Hình 21 - CAS – Proxy Flow

Logout Flow

Hình 22 - CAS – Logout Flow

Khi người dùng muốn đăng xuất khỏi một service, người dùng phải gọi logout URI.
CAS sẽ hủy Ticket-Granting Cookie và kiểm tra /logout URI có chứa parameter url
hay không. Nếu parameter “url” có giá trị, một thông báo đăng xuất thành công sẽ
được hiển thị với một liên kết đến giá trị url, ngược lại thì chỉ có thông báo đăng
xuất thành công.

Hạn chế

- CAS chỉ giải quyết authenticate, không authorization.

- Không Single Sign-Off.

- Ít tài liệu tham khảo.

32
.1.3.2 Triển Khai.
Phần này hướng dẫn về việc triển khai CAS cho các ứng dụng: Cấu hình CAS trên
Server Container, cấu hình ứng dụng để giao tiếp với CAS Server.

Hình 23 - Mô hình triển khai Sakai - Liferay - CAS

.1.3.2.1 Cấu hình Tomcat Server để chay CAS.


Triển khai CAS trên Tomcat Server. CAS sử dụng giao thức SSL cho nên cần phải
cấu hình Tomcat để hỗ trợ SSL.

Sử dụng keytool để self-sign một certificate.

Chạy cmd với quyền Administrator và chuyển đến thư mục bin của JDK_Home

33
//tao keystore
C:\Program Files\Java\jdk1.6.0>cd bin
C:\Program Files\Java\jdk1.6.0\bin>keytool -genkey -alias tomcat -keypass changeit -keyalg RSA
Enter keystore password: changeit
What is your first and last name?
[Unknown]: nonglam.cntt.com Chỗ này phải điền full
What is the name of your organizational unit?
[Unknown]: Information Systems
What is the name of your organization?
[Unknown]: Pacific Disaster Center
What is the name of your City or Locality?
[Unknown]: Kihei
What is the name of your State or Province?
[Unknown]: HI
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=localhost, OU=Information Systems, O=Pacific Disaster Center, L=Kihei, ST=HI, C=US
correct? [no]: yes

//xuất ra file certificate


C:\Program Files\Java\jdk1.6.0\bin>keytool -export -alias tomcat -keypass changeit -file server
Enter keystore password: changeit
Certificate stored in file <server>

//self-sign
C:\Program Files\Java\jdk1.6.0\bin>keytool -import -file server -keypass changeit -keystore
..\jre\lib\security\cacerts
Enter keystore password: changeit
Owner: CN=localhost, OU=Information Systems, O=Pacific Disaster Center, L=Kihei, ST=HI,
C=US
Issuer: CN=localhost, OU=Information Systems, O=Pacific Disaster Center, L=Kihei, ST=HI, C=US
Serial number: 462030d8
Valid from: Fri Apr 13 15:39:36 HST 2007 until: Thu Jul 12 15:39:36 HST 2007
Certificate fingerprints:
MD5: CC:3B:FB:FB:AE:12:AD:FB:3E:D 5:98:CB:2E:3B:0A:AD
SHA1: A1:16:80:68:39:C7:58:EA:2F:48:59:AA:1D:73:5F:56:78:CE:A4:CE

Chú ý: khi keystore được tạo, mặt đinh sẽ được lưu trong C:/Document and
Setting/User/.Keystore.

Cấu hình tomcat server.xml.

Mở file server.xml trong thư mục config của Tomcat. Bỏ comment element
“connector” cho cổng 8843 (SSL). Thêm vào những parameter cho keystore file,
keystore pass, trustore file và SSLEnable = true.

34
<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
<Connector port="8443" maxHttpHeaderSize="8192" SSLEnabled=”true”
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="C:/Documents and Settings/[user]/.keystore"
keystorePass="changeit"
truststoreFile="C:/Program Files/Java/jdk1.5.0_11/jre/lib/security/cacerts" />

.1.3.2.2 CAS Authenticate.


Sau khi triển khai CAS server, tiếp theo cấu hình cách xác thực cho CAS.

Hình 24 - Cơ chế xác thực mà CAS hỗ trợ

- LDAP

- JDBC

- RAIDUS

- Trusted

- X.509 Certificates

- Active Directory

- Generic

- Legacy

- Trusted

Trong phần này, tôi chọn hai cơ chế xác thực cho CAS: LDAP và JDBC.

Cấu hình CAS Server xác thực thông qua LDAP.

Sau khi tải CASServer về, bung ra một thự mục CAS-server-3.3.2.

35
- Mở pom.xml trong %CAS_HOME%/CAS-server-webapp, thêm phần
sau:

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>cas-server-support-ldap</artifactId>
<version>${project.version}</version>
</dependency>

- Mở deployerConfigContext.xml trong thự mục CAS_home/CAS-server-


webapp/src/main/webapp/WEB-INF và sửa lại nội dung như sau:

o Trong thẻ <beans>…</beans> thay thế


AuthenticatedLDAPContextSource bằng nội dung như sau:

<bean id="contextSource"
class="org.springframework.ldap.core.support.LdapContextSource">
<property name="pooled" value="true"/>
<property name="urls">
<list><value>ldap://nonglam.cntt.com:5389</value></list>
</property>

<property name="userDn" value="cn=Directory Manager"/>


<property name="password" value="123456"/>
</bean>

o Thiết lập AuthenticationHander: Thêm nội dung sau vào bên trong
thẻ <bean id=authenticationManager”>…</bean>.

<property name="authenticationHandlers" >


<list>
<bean
class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentials
AuthenticationHandler">
<property name="httpClient" ref="httpClient" />
</bean>

<bean class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler" >


<property name="filter" value="uid=%u" />
<property name="searchBase" value="ou=cntt,o=nonglam,dc=com" />
<property name="contextSource" ref="contextSource" />
</bean>
</list
</property>

- Build và Deploy.

o Build lại CAS-server với lệnh: mvn package install (đã cài đặt
maven).
36
o Sau build thành công chép CAS.war trong thư mục %CAS_HOME
%/CAS-server-webppp/target vào thư mục webapp của tomcat.

Chạy tomcat server và chạy https://nonglam.cntt.com:8443/CAS/login

Cấu hình CAS Server xác thực thông qua JDBC.

- Mở pom.xml trong %CAS_HOME%/CAS-server-webapp, thêm phần


sau:

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>cas-server-support-jdbc</artifactId>
<version>${project.version}</version>
</dependency>

- Chép jdbc driver vào ../WEB-INF/lib của CAS application. Trong


deployerConfigContext.xml, thêm nội dung sau bên trong thẻ <property
name="authenticationHandlers">

<property name="authenticationHandlers">
<list>
<bean
class="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAuthenticationHandler">
<property name=" tableUsers"><value>name of tables</value></property>
<property name="fieldUser"> <value>name of field username</value></property>
<property name="fieldPassword"><value>name of field password</value></property>
<property name="dataSource" ref="dataSource"/>
</bean>
<!--Query with login information -->
<bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler">
<property name="dataSource" ref="dataSource" />
<property name="sql" value="select [password] from [user] where lower(username) =
lower(?)" />
</bean>
</list>
</property>

- Đinh nghĩa datasoure để kết nối CSDL:

37
<!-- Data source definition -->
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName">
<value>com.mysql.jdbc.Driver</value>
</property>
<property name="url">
<value>jdbc:mysql://localhost:3306/mydb</value>
</property>
<property name="username"><value>root</value></property>
<property name="password"><value>password for root</value></property>
</bean>

- Buid CAS với lệnh : ‘mvn package install’

.1.3.2.3 Triển khai ứng dụng với CAS.


Để ứng dụng, giao tiếp được với CAS Server thì ứng dụng phải có thư viện
CAS Client để giao tiếp với CAS Server. Thực hiện theo từng bước sau:

- Cài đặt CAS client cho ứng dụng.

- Sử dụng một giải pháp bảo mật ứng dụng có hỗ trợ cơ chế xác thực CAS,
có thể chọn một trong các giải pháp sau:

o Security Filter

o Acegi Security

o Spring Security

Cài đặt CAS Client cho ứng dụng.

Tải CAS client (CASclient-2.1.1.jar): http://www.ibiblio.org/maven/CAS/jars

Chép tệp tin jar này vào thư mục lib (../WEB-INF/lib) của ứng dụng.

Chú ý: Đối với tomcat6 phải chép commons-logging-1.0.4.jar vào thư mục lib
của tomcat (lấy từ ../CAS-Home/module của CAS Server)
Để CAS hiểu được ứng dụng, trong web.xml phải thêm filter của CAS Client:

38
<filter>
<filter-name>CAS Filter</filter-name>
<filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
<param-value>https://nonglam.cntt.com:8443/cas/login</param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https:// nonglam.cntt.com:8443/cas/serviceValidate</param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value> nonglam.cntt.com:8080</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>CAS Filter</filter-name>
<url-pattern>/* </url-pattern>
</filter-mapping>

- Chú ý: Server name: nonglam.cntt.com (Full Domain) phải điền giống


như là certificate đã tạo khi cấu hình trong tomcat server.

Cài đăt Secruity Filter cho ứng dụng.

- Mặc định Security Filter chỉ hỗ trợ hai cơ chế xác thực cở bản là: FORM và
BASIC. Để Security Filter hiểu được CAS thì chúng ta chỉnh sửa lại soruce
code. Bởi vì, Khung đăng nhập của ứng dụng sẽ không sử dụng và thay vào
đó là khung đăng nhập của CAS.

- Chép các tệp tin jar trong lib của security filter: securityfilter.jar, CASclient-
2.1.2.jar, common-codec.jar, common-collection.jar, common-logging.jar,
common-beanutils.jar đến ../WEB-INF/lib của ứng dụng.

- Chỉnh sửa web.xml như sau:

39
<filter>
<filter-name>Security Filter</filter-name>
<filter-class>org.securityfilter.filter.SecurityFilter</filter-class>
<init-param>
<description> Configuration file location </description>
<param-name>config</param-name>
<param-value>/WEB-INF/securityfilter-config.xml</param-value>
</init-param> Value = “true” khi ứng dụng
<init-param> chạy độc lập, không cần single
<description>Validate config file if set to true</description>sign on
<param-name>validate</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<description> As an example a login form can define "logMeIn" as it
action in place of the standard "j_security_check" which is a specia
flag user by app servers for container managed security.
</description>
<param-name>formPattern</param-name>
<param-value>/logMeIn</param-value>
</init-param>
</filter>

- Tạo ra file securityfilter-config.xml để thiết lập chính sách bảo mật

40
<securityfilter-config>
<security-constraint>
<web-resource-collection> Phân quyền cho tài
<web-resource-name>Admin Pages</web-resource-name> nguyên: chỉ định role cụ
<url-pattern>/admin/*</url-pattern> thể cho các tài nguyên
</web-resource-collection> cần bảo vệ
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
Thay thế FORM medthod của
ứng dụng bằng CAS method.
<login-config> Và loại bỏ các login page của
<auth-method>CAS</auth-method> ứng dụng
<form-login-config>
<form-default-page>/commons/default.jsp</form-default-page>
</form-login-config>
</login-config>

<!-- start with a Catalina realm adapter to wrap the Catalina realm defined below -->
<realm className="org.securityfilter.realm.catalina.CatalinaRealmAdapter" />
<realm className="org.apache.catalina.realm.JDBCRealm">
<realm-param name="driverName" value="com.mysql.jdbc.Driver"/>
<realm-param name="debug" value="0"/>
<realm-param name="connectionURL" value="jdbc:mysql://localhost/objtest"/>
<realm-param name="connectionName" value="root"/> Chỉnh định
<realm-param name="connectionPassword" value="123456"/> đến csdl
<realm-param name="userTable" value="user"/> người dùng
<realm-param name="userNameCol" value="username"/> của ứng
<realm-param name="userCredCol" value="password"/> dụng (trước
<realm-param name="userRoleTable" value="user"/> đây thay vì
cấu hình
<realm-param name="roleNameCol" value="groupName"/>
ngay trong
<!--realm-param name="digest" value="MD5"/-->
web server)
</realm>

- Cấu hình CASclient cho ứng dụng. Chú ý CAS-filter phải đặt vị trí đầu
web.xml.

.1.3.2.4 Cấu hình Liferay sử dụng CAS và LDAP.


Khi cấu hình Liferay sử dụng CAS với mục đích là Single Sign On với những ứng
dụng khác. Thông thường, để lưu trữ thông tin người dùng thì LDAP là lựa chọn tốt
nhất. Vì thế, khi triển khai, ta phải cấu hình Liferay cho CAS và LDAP.

Liferay và CAS.

Trước hết, tạo và import certificate vào jre của Liferay. Filter server.crt đã tồn tại khi
cài đặt CAS server. Chỉ cần import nó vào keystore cacerts của jre Liferay.

41
//xuất ra file certificate (nếu chưa có)
C:\Program Files\Java\jdk1.6.0\bin>keytool -export -alias tomcat -keypass changeit -file
server.crt
Enter keystore password: changeit
Certificate stored in file <server>

//self-sign
C:\Program Files\Java\jdk1.6.0\bin>keytool -import -file server.crt -keypass changeit
-keystore ..\liferay-portal\tomcat-6.0.18\jre\win\lib\security\cacerts (path của cacerts của
liferay)
Enter keystore password: changeit
Owner: CN=localhost, OU=Information Systems, O=Pacific Disaster Center, L=Kihei,
ST=HI, C=US
Issuer: CN=localhost, OU=Information Systems, O=Pacific Disaster Center, L=Kihei,
ST=HI, C=US
Serial number: 462030d8
Valid from: Fri Apr 13 15:39:36 HST 2007 until: Thu Jul 12 15:39:36 HST 2007
Certificate fingerprints:
MD5: CC:3B:FB:FB:AE:12:AD:FB:3E:D 5:98:CB:2E:3B:0A:AD
SHA1: A1:16:80:68:39:C7:58:EA:2F:48:59:AA:1D:73:5F:56:78:CE:A4:CE

Đăng nhập vào Liferay với quyền admin. Vào controlpanel  setting 
authentication, chọn tag CAS và điền thông tin về CAS Server.

Hình 25 - Cấu hình CAS - Liferay

Chú ý: Logout URL:

https://nonglam.cntt.com:8443/CAS/logout?
url=http://nonglam.cntt.com:18080/web/guest. Khi đăng xuất thì CAS hủy ticket
granting và sau đó sẽ chuyển về trang guest của Liferay.

Liferay và LDAP.

Dữ liệu sẽ import vào Liferay từ LDAP. Chọn thẻ LDAP và cấu hình các mục sau:

- Authentication:
42
Hình 26 - Cấu hình Liferay - LDAP

- Connection: Điền đầy đủ thông tin về LDAP Sever.

Hình 27 - Cấu hình Liferay - LDAP (t.t)

- Users:

Hình 28 - Cấu hình Liferay - LDAP (t.t)

- User mapping: Điền đầy đủ thông tin các thuộc tính tên trong LDAP, thông
tin này map các giá trị tương ứng trong LDAP với các trường trong Liferay.

43
Hình 29 - Cấu hình Liferay - LDAP (t.t)

- Groups: Map group trong LDAP, tương ứng với trong Liferay.

Hình 30 - Cấu hình Liferay - LDAP (t.t)

- Import/Export: Kích hoạt chức năng Import để dữ liệu trong LDAP được
import vào Liferay và chọn khoảng thời gian để cập nhật (Import Interval).

Hình 31 - Cấu hình Liferay - LDAP (t.t)

44
.1.3.2.5 Cấu hình Sakai sử dụng CAS.
Cấu hình web.xml của login-tool.

- Mở $SAKAI_SRC/login/login-tool/tool/src/webapp/WEB-INF/web.xml,
thêm vào filter có nội dung như sau:

<filter>
<filter-name>sakai.cas</filter-name>
<filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
<param-value>https://nonglam.cntt.com:8443/cas/login</param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://nonglam.cntt.com:8443/serviceValidate</param-value>
</init-param>
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value>nonglam.cntt.com:28080</param-value> Server name và port của
</init-param>
ứng dụng.
<init-param>
<param-name>edu.yale.its.tp.cas.client.filter.wrapRequest</param-name>
<param-value>true</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>sakai.cas</filter-name>
<url-pattern>/container</url-pattern>
</filter-mapping>

- Thêm filter-mapping cho sakai request

<filter-mapping>
<filter-name>sakai.request</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>

Cấu hình pom.xml của login-tool.

Sửa $SAKAI_SRC/login/login-tool/tool/pom.xml (cho sakai 2.5). Thêm vào


CASclient (Khi build maven sẽ tải CASclient về).

45
<dependency>
<groupId>cas</groupId>
<artifactId>casclient</artifactId>
<version>2.1.1</version>
</dependency>

Chỉnh sửa file sakai.properties.

Chúng ta cần login/logout thông qua CAS, thì phải bỏ đi username/password ở phía
trên của sakai login và cho phép container quản lý đăng nhập thông qua CAS

# Remove the username/password boxes at the top by setting this to false


top.login = false

# Let the container handle logins - ie to use single sign-on.


container.login = true

# Force logouts via CAS also - your requirements will be different for this.
# The URL below allows us to logout via CAS and then be redirected back to our
Sakai server.
loggedOutUrl=https://localhost:8443/cas/logout?url=http://localhost:8080/

Rebuild login project và kiểm tra.

- Build lại login project: Chuyển đến login-project và chạy lệnh: “mvn package
install”

- Khởi động lại server và chạy sakai home page: http://host:port/portal

- Nhấn login, hệ thống sẽ redirect đến trang đăng nhập của CAS.

.1.4. Các giải pháp bảo mật ứng dụng.


.1.4.1Triển Khai.
Ứng dụng và JDBC.

- File application-context-security có nội dung sau:

46
<bean id="authenticationManager"
class="org.acegisecurity.providers.ProviderManager">
<property name="providers">
<list>
<ref bean="daoAuthenticationProvider" />
</list>
</property>
</bean>

<bean id="daoAuthenticationProvider"
class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">
<property name="userDetailsService">
<ref bean="userDetailsService" />
</property>
<property name="userInfoObjectTypes">
<list>
<value>Teacher</value>
<value>Admin</value>
<value>Student</value>
</list>
</property>
</bean>

<bean id="userDetailsService"
class="AuthenticationJdbcDaoImpl">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>

<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource"
>
<property name="driverClassName">
<value>com.mysql.jdbc.Driver</value>
</property>
<property name="url">
<value>jdbc:mysql://localhost:3306/test</value>
</property>
<property name="username">
<value>root</value>
</property>
<property name="password">
<value>123456</value>
</property>
</bean>

Ứng dụng, CAS và JDBC.

- Thêm filter chain vào web.xml.

47
<filter>
<filter-name>Acegi Filter Chain Proxy</filter-name>
<filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>org.acegisecurity.util.FilterChainProxy</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>Acegi Filter Chain Proxy</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

- Thêm file cấu hình application-context-security trong web.xml.

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/applicationContext-jdbc.xml
/WEB-INF/applicationContext-acegi-security.xml
</param-value>
</context-param>

- Thêm context listener vào web.xml.

<listener>
<listener-
class>org.springframework.web.context.ContextLoaderListener</listener-
class>
</listener>

- Thêm applicationContext-acegi-security.xml có nội dung sau:

48
<bean id="authenticationManager"
class="org.acegisecurity.providers.ProviderManager">
<property name="providers">
<list>
<ref bean="daoAuthenticationProvider" />
</list>
</property>
</bean>
<bean id="daoAuthenticationProvider"
class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">
<property name="userDetailsService">
<ref bean="userDetailsService" />
</property>
<property name="userInfoObjectTypes">
<list>
<value>Teacher</value>
<value>Admin</value>
<value>Student</value>
</list>
</property>
</bean>
<bean id="userDetailsService"
class="AuthenticationJdbcDaoImpl">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName">
<value>com.mysql.jdbc.Driver</value>
</property>
<property name="url">
<value>jdbc:mysql://localhost:3306/test</value>
</property>
<property name="username">
<value>root</value>
</property>
<property name="password">
<value>123456</value>
</property>
</bean>

- Thêm những thư viện sau vào ../lib của ứng dụng.

 acegi-security-0.8.2.jar
 acegi-security-CAS-0.8.2.jar
 CAS.jar
 commons-codec-1.3.jar
 commons-collections-3.1.jar
 commons-logging.jar
 ehcache-1.1.jar
 log4j-1.2.9.jar
 mysql-connector-java-3.0.16-ga-bin.jar
 oro-2.0.8.jar
 spring-1.2.1.jar

49
Chương .2 Tìm hiểu Sakai LMS.

.2.1. Giới thiệu Sakai project.


Sakai (http://sakaiproject.org/) là một cộng đồng các viện nghiên cứu, các tổ chức
thương mại và các cá nhân hợp tác với nhau để phát triển một Môi trường Cộng tác
và Học tập chung (Collaboration and Learning Environment - CLE).

Sakai ban đầu được phát triển dựa trên các công cụ được xây dựng bởi 5 trường đại
học Indiana University, Massachusetts Institute of Technology, Stanford University,
University of Michigan, Polytechnic University of Valencia.

Sau phiên bản đầu tiên, họ mời thêm các học viện khác với tư cách là những người
cộng tác (Sakai Partners Program).

Hiện tại việc phát triển Sakai được thực hiện dưới sự cộng tác của nhiều học viện,
trường đại học, các tổ chức thương mại, những cá nhân tình nguyện và tổ chức
Sakai.

Tổ chức Sakai (Sakai Foundation).

Là một thành viên được hơn 100 tổ chức, học viện, tài trợ kinh phí khiêm tốn cho
những hoạt động phi lợi nhuận bao gồm việc quản lý các tài nguyên trí tuệ của
Sakai, bảo trì hệ thống Sakai, phát hành Sakai và là người phát ngôn của Sakai.

Cộng đồng Sakai (Sakai Community).

Là sự đóng góp của nhiều tổ chức và cá nhân trên thế giới. Cộng đồng Sakai chịu
trách nhiệm về mọi khía cạnh của Sakai CLE. Họ tin rằng việc phát triển mô hình
dựa vào cộng động sẽ tạo ra sản phẩm tốt nhất.

Các học viện dù lớn hay nhỏ đều có thể hợp tác với các đối tác thương mại của
Sakai, những người cung cấp host và các dịch vụ phát triển, hỗ trợ để ứng dụng
Sakai vào học viện của mình.

50
Sakai CLE là một phần mềm giáo dục miễn phí, mã nguồn mở được phân phối theo
Giấy phép Giáo dục Cộng đồng (Educational Community License - một kiểu của
giấy phép mã nguồn mở). Sakai CLE được dùng để dạy học, để nghiên cứu và để
cộng tác nhiều người với nhau. Hệ thống này là một dạng của Hệ quản trị đào tạo
(Learning Management System - LMS). Vào tháng 7 năm 2007, Sakai là sản phẩm
được hơn 150 viện nghiên cứu tham gia phát triển và được thí điểm ở hơn 100 nơi
khác.

Hiện nay, Sakai được áp dụng cho hơn 160 học viện, trường đại học, cao đẳng…
trên toàn thế giới.

Hình 32 - Các nơi nghiên cứu và sử dụng Sakai

.2.2. Tính năng.


Sakai bao gồm nhiều tính năng chung của các Hệ quản trị đào tạo, bao gồm đưa lên
các tài liệu hướng dẫn, sách giáo trình, mục thảo luận, trao đổi trực tuyến, bài tập
lớn, và các bài kiểm tra online.

Thêm vào đó, Sakai còn cung cấp một bộ công cụ làm việc nhóm dùng cho nghiên
cứu và các dự án nhóm. Để hỗ trợ các tính năng này, Sakai đã thêm vào khả năng
thay đổi thiết lập của tất cả mọi công cụ dựa trên vai trò, thay đổi quyền hệ thống
tùy theo người dùng. Nó cũng tích hợp một wiki, mailing list và lưu trữ, bộ đọc
RSS.

51
.2.3. Bộ công cụ để dạy và học, quản lý điểm số.

Bài tập đã
Sổ điểm
được nộp

Bài tập đã
Bài tập
được gửi

Bài kiểm Bài kiểm tra, thi


tra, thi đã được gửi

Bài kiểm tra, thi


Sổ điểm
đã được nộp

Hình 33- Quan hệ giữa các công cụ dạy và học

.2.3.1 Syllabus – Đề cương bài giảng.

.2.3.1.1 Tạo đề cương.


Chọn Syllabus > Create/Edit > Add.

Title: Đặt tên cho đề cương môn học.

Content: Nơi soạn thảo nội dung của đề cương.

Public View: Bất kỳ ai cũng có thể xem được đề cương.

Only for Site: Chỉ cho phép thành viên khóa học được xem đề cương.

Add Attachments: Đính kèm tệp tin cho đề cương.

Email Notification: Thông báo mail về đề cương môn học.

52
Post: Đưa đề cương lên.

Preview: Xem lại đề cương.

Save Draft: Lưu đề cương thành bản nháp để chỉnh sửa sau.

.2.3.1.2 Lấy từ đề cương có sẵn trên web.


Chọn Syllabus > Create/Edit > Redirect > Nhập vào đường dẫn đến trang web.

.2.3.2 Gradebook – Sổ điểm.


Giúp giảng viên tính điểm, lưu trữ và thông báo điểm cho sinh viên.

Tự động tính toán điểm của khóa học.

Có thể cho xem, nhập mới, chỉnh sửa và công bố đến sinh viên điểm và các lời phê.

Có thể chuyển điểm vào từ các công cụ khác như Test and Quizzes, Assignment.

Xuất/Nhập điểm và xếp loại ra dạng .csv.

Hình 34 – Sổ điểm

All Grades: Xem tất cả các điểm của tất cả của sinh viên.

Course Grades: Xem điểm khóa học của tất cả các sinh viên.

Gradebook Setup: Một số thiết lập cho sổ điểm.

53
Course Grade Options: Tùy chọn điểm cho khóa học (quy định cách đánh giá khóa
học theo điểm chữ (A-F) hoặc đánh giá theo đậu/rớt).

Import Grades: Nhập điểm số từ tệp tin Bảng tính và một số tùy chọn khác.

Add Gradebook Item: Thêm một mục sổ điểm.

Import gradebook item from spreadsheet.

Gradebook Items Summary.

• Title: Tiêu đề của sổ điểm.

• Edit: Chỉnh sửa.

• ClassAvg: Điểm trung bình của lớp (trung bình tất cả các sinh viên).

• Due Date: Ngày hết hạn của sổ điểm.

• Released to Students: đã cho sinh viên xem sổ điểm này chưa.

• Included in Course Grade: Mục sổ điểm này có được tính vào trong điểm
chung của khóa học hay không.

.2.3.2.1 Quy định cách đánh giá môn học.


Giảng viên có thể quy định cách đánh giá cuối môn học với kết quả Đậu/Rớt hoặc
điểm bằng chữ A-F.

Hình 35 - Sakai Gradebook - Quy định cách đánh giá môn học

54
Chọn công cụ Grade Book > Change course grade options.

Hình 36 - Sakai Gradebook - Quy định cách đánh giá môn học (tt)

Display course grade to students now: Chọn nếu muốn hiển thị kết quả điểm môn
học đến thời điểm hiện tại cho sinh viên.

Grade Type:

• Letter Grades (with +/-): Đánh giá kết quả cuối cùng của môn học theo điểm
chữ từ A-F

• Pass/Not Pass: Đánh giá kết quả cuối cùng của môn học là đậu hay rớt.

Rồi điền bên dưới (hoặc để mặc định) tỷ lệ % điểm sinh viên phải đạt được để tương
ứng vớt kết quả đánh giá.

.2.3.2.2 Quy định hệ số điểm cho bài kiểm tra/bài tập.


Giáo viên quy định bài kiểm tra/bài tập theo các nhóm rồi quy định hệ số điểm
tương ứng cho mục đó.

Ví dụ: Bài thi giữa kìa chiếm 40% tổng điểm, bài thi cuối kỳ chiếm 40% tổng điểm,
các bài tập chiếm 20% tổng điểm (lưu ý tổng các tỷ lệ phải đủ 100%).

55
Hình 37 - Sakai Gradebook - Quy định hệ số điểm cho bài kiểm tra/bài tập

Chọn công cụ Gradebook > Gradebook Setup.

Categories & Weighting: Phân loại cho bài kiểm tra/bài tập và gán cho hệ số điểm.

Sau đó điền các phân loại và tỷ lệ điểm tương ứng.

Chọn Save Changes để lưu các thay đổi.

Hình 38 - Quy định hệ số điểm cho bài kiểm tra/bài tập (tt)

Sau khi lưu các thay đổi, trở lại Gradebook Items.

Đối với các Mục sổ điểm (Gradebook Item) đã tạo trước đó (nếu có) mà chưa phân
loại (Unassigned) thì chọn Edit để phân loại.

56
Hình 39 - Quy định hệ số điểm cho bài kiểm tra/bài tập (tt)

.2.3.2.3 Cách tạo sổ điểm.


Chọn Gradebook > Add Gradebook Item.

Title: Tiêu đề sổ điểm.

Gradebook Item Point Value (điểm thực của sinh viên trong mục sổ điểm được
tính dựa trên tỉ lệ điểm bài tập/ Gradebook Item Point Value).

Ví dụ: Bài tập A sử dụng mục sổ điểm B này (với Gradebook Item Point Value =
20), nếu bài tập A sinh viên được 10 điểm thì điểm thực tính theo mục sổ điểm B là
10/20.

Due Date: Ngày hết hạn của sổ điểm.

Release this item to Students: Cho phép sinh viên thấy sổ điểm này.

Include this item in course grade calculations: Tính vào điểm khóa học.

.2.3.2.4 Sử dụng sổ điểm.


Ghi chú: Một mục trong sổ điểm (Gradebook) có thể được tạo bằng công cụ
Gradebook hoặc cũng có thể được tạo từ các công cụ khác như Bài tập
(Assginment), Kiểm tra (Test and Quizzes).

57
Trong phần tạo bài tập, phần Grading, chọn Associate with existing Gradebook
entry để sử dụng một mục trong sổ điểm đã có sẵn hoặc chọn Add Assginment to
Gradebook để tạo mới một mục sổ điểm cho bài tập này.

Hình 40 - Sử dụng sổ điểm khi tạo bài tập

Trong phần tạo bài kiểm tra (Test and Quizzes).

Vào mục Settings (cài đặt một số thông tin cho bài kiểm tra), mục Grading, chọn
Grades sent to Gradebook.

Hình 41 - Sử dụng sổ điểm khi tạo bài kiểm tra

.2.3.3 Assignment – Bài tập.


Giúp giảng viên tạo, gửi bài tập cho sinh viên và chấm điểm trực tuyến, cho lời phê
các bài tập đó.

Hỗ trợ nhiều cách tính điểm, đánh giá (điểm chữ, điểm số, phần trăm, đậu/rớt).

.2.3.3.1 Tạo bài tập.


Chọn trang học thích hợp, nơi mà người dùng có tư cách giảng viên.

Chọn Assigment > Add, để bắt đầu tạo một bài tập.
58
Title: Tên bài tập.

Open Date: Ngày bài tập được gửi đến sinh viên. Sinh viên không thể thấy và làm
bài nếu chưa đến ngày này.

Due Date: Hạn nộp bài.

Accept until: Hạn nộp cuối, sau ngày này sinh viên không thể làm hay nộp bài cho
giáo viên.

Student Submission: Chọn hình thức để sinh viên nộp bài

• Inline and Attachments: Nộp dạng chữ và tệp tin đính kèm.

• Inline only: Chỉ nộp dạng chữ.

• Attachments only: Chỉ dùng tệp tin đính kèm.

• Non-electronic: Không nộp qua site khóa học (có thể là nộp trực tiếp với
giáo viên).

Grade Scale: Cách tính điểm.

• Ungrade: Không chấm điểm (chỉ dùng làm bài tập mang tính rèn luyện).

• Letter Grade: Điểm chữ (A-F).

• Points: Điểm số (0-10).

• For points, enter maximum possible: Phải quy định điểm tối đa cho bài tập.

• Pass/Fail: Đánh giá đậu/rớt.

• Checkmark: Đánh giá chấp nhận/không chấp nhận.

Assginment Instruction: Phần hướng dẫn làm bài của giáo viên.

Add an announcement about the open date to Announcements: Thông báo ngày
giao bài tập xuống sinh viên vào bảng thông báo.

59
Add honor pledge: Thêm cam kết danh dự (cam kết sinh viên không nhận sự giúp
đỡ của người khác lúc làm bài tập này).

Grading: Ghi nhận điểm của bài tập vào sổ điểm.

• Do not add assignment to Gradebook: Không đưa điểm bài tập vào sổ
điểm.

• Add Assignment to Gradebook: Đưa điểm bài tập vào sổ điểm.

• Associate with existing Gradebook entry: Đưa điểm bài tậo vào sổ điểm và
dùng chung cột điểm với một bài tập đã có trong sổ điểm (dùng khi giáo viên
muốn cho sinh viên gở điểm xấu của bài tập trước).

Submission Notification Email Options: Tùy chọn thông báo mail đến giáo viên
khi có sinh viên nộp bài.

Add Attachment (hay Add/Remove Attachment): Thêm hoặc bớt tệp tin đính
kèm cho bài tập.

• Khi bài tập chưa có tệp tin đính kèm, người dùng sẽ thấy Add Attachment để
thêm tệp tin đính kèm.

• Khi bài tập đã có tệp tin đính kèm, người dùng sẽ thấy Add/Remove
Attachment để thêm hoặc bỏ tệp tin đính kèm.

Nếu đã đính kèm, người dùng sẽ thấy Items to attach, nhấn Remove để xóa.

Upload local file: Chọn tệp tin trên máy tính.

or a URL: Lấy liên kết của tệp tin từ trang web khác.

Select a resource: Chọn tệp tin từ resource của khóa học (Chọn Attach a copy của
tệp tin muốn tải lên từ resource).

Post: Hoàn thành việc tạo bài tập.

Preview: Xem lại bài tập vừa tạo.


60
Save Draft: Lưu bài tập dạng nháp để chỉnh sửa sau.

Cancel: Hủy bỏ, không tạo bài tập.

.2.3.3.2 Xem – Chỉnh sửa – Chấm điểm bài tập.


View - Assigment List: Xem các bài tập đã tạo.

Hình 42 - Xem danh sách bài tập

Assigment title: Tên bài tập.

Status: Trạng thái của một bài tập.

• Not Open: Bài tập này chưa đến ngày giao xuống cho sinh viên .

• Open: Bài tập này đã được giao xuống cho sinh viên.

• Due: Bài tập đến hạn nộp.

• Close: Bài tập đã hết hạn nộp.

• Draft: Bài tập đang được chỉnh sửa, chưa giao xuống sinh viên.

Open: Ngày giờ bài tập sẽ được giao xuống cho sinh viên.

Due: Ngày giờ bài tập đến hạn nộp.

In / New: Tổng số các bài nộp của sinh viên (In) và số bài nộp giáo viên chưa chấm
điểm (New).

61
Scale: Loại điểm của một bài tập.

Xem lại nội dung bài tập: Nhấn vào tên bài tập (ví dụ: Bài tập 1) để xem với tư
cách giáo viên hoặc tư cách sinh viên (student view).

Chỉnh sửa bài tập: Nhấn Edit để chỉnh sửa toàn bộ thông tin và nội dung bài tập.
Với những bài tập hết hạn nộp hay đã có sinh viên nộp bài, giáo viên sẽ nhận được
cảnh báo nhắc nhở trước khi chỉnh sửa. Tùy theo những chỉnh sửa của giáo viên mà
các bài sinh viên đã nộp sẽ bị ảnh hưởng (thường là mất bài).

Tạo bản sao của bài tập: Nhấn Duplicate để tạo ra một bài tập hoàn toàn giống bài
tập hiện tại.

Chấm điểm: Nhấn Grade, màn hình hiển thị tương tự bên dưới, nhấn vào tên sinh
viên để chấm điểm bài làm cho sinh viên.

Hình 43 – Chấm điểm

View - Assigment List by Student: Chỉ xem danh sách sinh viên và trạng thái các
bài tập giáo viên đã giao xuống cho sinh viên.

62
Hình 44 - Xem danh sách bài tập theo sinh viên

.2.3.3.3 Xem bài tập dưới góc nhìn của sinh viên.

Hình 45 - Xem bài tập dưới góc nhìn của sinh viên

Submit as Student: Thử làm bài như sinh viên(để ước lượng thời gian làm bài, độ
khó bài tập, …).

.2.3.4 Tests and Quizzes – Kiểm tra.


Giúp giảng viên tạo bài kiểm tra hoặc các bảng thăm dò ý kiến.

Điểm được tự động chấm.

63
Có thể có nhiều loại câu hỏi trong bài kiểm tra (bảng thăm dò ý kiến):

• Multiple Choice: Chọn một hoặc nhiều câu trả lời cho một câu hỏi.

• Servey: Thăm dò ý kiến với các mức ý kiến đã quy định sẵn cho một câu hỏi
thăm dò.

• Short Answer/Essay: Bài tiểu luận ngắn.

• Fill in the Blank: Điền vào chỗ trống.

• Numeric Response: Câu trả lời dạng số.

• Matching: Câu hỏi dạng nối hai cột để có kết quả đúng.

• True False: Chọn lựa đúng hoặc sai.

• Audio Recording: Trả lời bằng cách ghi âm trực tiếp.

• File Upload: Câu trả lời là tệp tin đính kèm.

• Copy from Question Pool: Chọn các câu hỏi có sẵn từ ngân hàng câu hỏi.

.2.3.4.1 Tạo ngân hàng câu hỏi.


Chọn Tests & Quizzes > Question Pools > Add New Pools.

Pool Name: Tên ngân hàng câu hỏi.

Creator: Người tạo ngân hàng câu hỏi (tên người đã đăng nhập và tạo ra ngân hàng
câu hỏi này, không thay đổi được).

Department/Group: Tên Phòng Ban/Nhóm chủ ngân hàng câu hỏi.

Description: Mô tả ngắn về ngân hàng câu hỏi.

Objectives: Mô tả ngắn mục đích ngân của ngân hàng câu hỏi.

Keywords: Từ khóa cho ngân hàng câu hỏi để hỗ trợ tìm kiếm nhanh ngân hàng câu
hỏi này.
64
Công cụ cũng hỗ trợ phân cấp nhiều nhiều ngân hàng câu hỏi con. Ví dụ, trong ngân
hàng câu hỏi môn A, có ngân hàng các câu hỏi một lựa chọn, ngân hàng câu hỏi
nhiều lựa chọn, ngân hàng câu hỏi đúng sai…

Hình 46 - Sakai Test & Quizzes - Tạo ngân hàng câu hỏi

Chọn Add bên dưới Ngân hàng câu hỏi muốn tạo ngân hàng con, rồi tạo bình
thường.

Các ngân hàng con sẽ được hiển thị bên dưới.

.2.3.4.2 Thêm câu hỏi vào Ngân hàng câu hỏi.


Nhấn vào tên của Ngân hàng câu hỏi. Chọn Add tương ứng với Questions để thêm
câu hỏi.

Hình 47 - Sakai Test & Quizzes - Thêm câu hỏi

Các bước khi tạo bất kỳ loại câu hỏi nào:

65
Hình 48 - Soạn nội dung câu hỏi

• Answer Point Value: Điểm cho câu hỏi (trừ loại survey).

• Soạn nội dung câu hỏi.

• Đặt câu hỏi vào phần (part) trong bài kiểm tra (thi), đưa câu hỏi vào ngân
hàng câu hỏi.

• Soạn các phản hồi (feedback) cho câu hỏi.

Hình 49 - Phản hồi đáp án cho sinh viên

.2.3.4.3 Tạo bài kiểm tra.


Chọn Test & Quizes > Assessment > Add Assessment.

Title: Tên bài kiểm tra (thi).


66
Chọn Create (hoặc Quick Create) để tạo bài kiểm tra.

Create: Bài kiểm được tạo, giáo viên tiến hành tạo các câu hỏi cho bài kiểm tra
(xem phần tạo câu hỏi và ngân hàng câu hỏi).

Quick Create: Tạo nhanh các câu hỏi bẳng dạng text (theo định dạng đã được sakai
quy định), cách này một lúc tạo được nhiều câu hỏi.

.2.3.5 Presentation – Trình diễn slide bài giảng.


Giúp giảng viên tạo các slide bài giảng dưới dạng hình. Việc này giúp cho giảng
viên có thể trình chiếu cho người xem. Khi giảng viên di chuyển các slide bài giảng
trong lúc giảng dạy, màn hình của sinh viên cũng sẽ thay đổi, để theo dõi bài giảng
của giáo viên.

.2.3.5.1 Tạo một bài giảng.


Vào công cụ Resource, tạo một thư mục tên Presentations.

Tạo các thư mục con bên trong thư mục Presentation > Tải hình ảnh các slide vào
các thư mục này.

Các thư mục này sẽ hiển thị trong Presentation và cho phép trình chiếu như trình
chiếu slide.

Hình 50 - Sakai Presentations

67
.2.4. Bộ công cụ giao tiếp giữa giảng viên và sinh viên.

.2.4.1 Announcement – Thông báo.


Giúp giảng viên thông báo các tin tức về khóa học cho sinh viên.

Thông báo có thể được giảng viên tạo trực tiếp hoặc thông qua một công cụ khác
(như Assignement – tạo thông báo khi bài tập được giảng viên đưa ra).

.2.4.1.1 Cách tạo thông báo.


Chọn Announcement > Add.

Announcement title: Tiêu đề của thông báo.

Body: Nội dung thông báo.

Access: Quản lý việc xem thông báo.

Only members of this site can see this announcement: Chỉ cho phép các thành
viên của khóa học xem thông báo này.

This announcement is publicly viewable: Mọi người đều có thể xem.

Availability:

• Show: Luôn luôn hiển thị thông báo này.

• Hide: Luôn luôn ẩn thông báo này.

Specify Dates: Chỉ định khoảng thời gian thông báo được hiển thị.

Beginning: Ngày bắt đầu của thông báo.

Ending: Ngày kết thúc thông báo.

Add Attachments: Đính kèm tệp tin cho thông báo.

Email Notification: Thông báo mail.

• All participants: Thông báo đến tất cả các thành viên của khóa học.

68
• Only participants who opted in: Chỉ thông báo đến các thành viên chỉ định.

• No Notification: Không thông báo mail.

Add Announcement: Tiến hành thêm thông báo.

Preview: Xem lại thông báo.

.2.4.1.2 Xem – Chỉnh sửa thông báo.


View: Các thông báo trong bảng thông báo.

• All: Xem tất cả các thông báo.

• Public: Chỉ xem các thông báo chung.

• By group: Xem thông báo của các nhóm.

Nhấn vào tiêu đề thông báo để xem chi tiết thông báo.

Nhấn vào Edit để chỉnh sửa thông báo.

Để xóa thông báo, chọn ô Remove, nhấn Update bên dưới.

.2.4.1.3 Kết hợp thông báo của trang học khác.


Chọn Announcement > Merge.

Chọn các trang web muốn lấy thông báo > Save. Các sự kiện này sẽ được thêm vào
bảng thông báo của khóa học hiện tại.

Ghi chú: Những thông báo lấy từ site khác sẽ không được chỉnh sửa hay xóa.

.2.4.2 Schedule – Lịch công tác.


Giúp giảng viên ghi chú các sự kiện đặc biệt trong khóa học.

Giảng viên có thể tạo sự kiện trực tiếp hoặc thông qua một công cụ khác (như
Assignement – tạo sự kiện cho báo cho sinh viên biết ngày hết hạn làm bài tập).

69
.2.4.2.1 Tạo một sự kiện trong lịch công tác.
Chọn Schedule > Add.

Title: Tên sự kiện.

Date: Ngày sự kiện diễn ra.

Start Time: Thời điểm bắt đầu sự kiện.

Duration: Khoảng thời gian sự kiện diễn ra.

End Time: Thời điểm kết thúc sự kiện.

Message: Nội dung của sự kiện.

Display to site: Hiển thị trên bảng lịch biểu của khóa học (mặc định được chọn).

Frequency: Chọn số lần lặp lại cho sự kiện.

• Once: Chỉ xuất hiện1 lần, không lặp lại.

• Daily: Hằng ngày.

• Weekly: Hằng tuần.

• Monthly: Hằng tháng.

• Yearly: Hằng năm.

Event Type: Chọn loại sự kiện.

70
Academic Calendar: Lịch học

Activity: Hoạt động Computer Session: Học vi tính

Cancellation: Hủy hẹn Deadline: Hạn cuối nộp bài

Class section – Discussion: Thảo luận Exam: Kiểm tra

Class section – Lab: Thực hành Multidisciplinary Conference: Hội nghị

Class section – Lecture: Thuyết trình Quiz: Thi

Class section - Small Group: Nhóm Web Assignment: Bài tập trên web

Event Location: Mô tả nơi sự kiện diễn ra.

Add Attachments: Thêm file đính kèm cần thiết cho sự kiện.

Save Event: Lưu lại sự kiện vào lịch công tác.

.2.4.2.2 Lấy sự kiện từ trang khác.

Hình 51 - Lấy sự kiện từ trang khác

Chọn Schedule > Merge > chọn trang web muốn lấy sự kiện > Save.

.2.5. Hiện thực Sakai Course Management System (Sakai-CMS).


.2.5.1 Giới thiệu Sakai CMS.
Sakai là một hệ thống quản lý học trực tuyến, và việc quản lý của nó liên quan đến
các khóa học, giảng viên, sinh viên, việc đăng ký học.

Ban đầu, các nhóm phát triển Sakai hình như ra mối quan hệ quá đơn giản giữa việc
quản lý học của các học viện với việc hiện thực chúng lên website, nên Sakai phiên

71
bản đầu không cho phép người dùng can thiệp vào việc quản lý học được Sakai định
nghĩa sẵn.

Nhưng về sau, nhận thấy được sự phức tạp và khác biệt rõ rệt giữa việc định nghĩa
cũng như hiện thực quản lý học của các học viện, nên vào khoảng năm 2005-2007,
một nhóm các trường đại học đã hợp tác nghiên cứu, định nghĩa, hiện thực và đưa
vào Sakai 2.4 một hệ thống quản lý học phức tạp và linh động hơn.

Khi đó các học viện, trường học hoặc có thể sử dụng lại Sakai CMS được hiện thực
sẵn để áp dụng vào việc quản lý học của mình, hoặc tự hiện thực lại interface của
Sakai CMS cho phù hợp với mô hình quản lý của mình.

.2.5.2 Một số khái niệm trong Sakai CMS.


AcademicSession: Thường để biểu diễn khái niệm 1 học kỳ. Nhưng tổng quát là để
thể hiện một khoảng thời gian mà các khóa học được mở.

CanonicalCourse: Để mô tả tổng quát một môn học, một chương trình học.

CourseOffering: Là một hiện thực của thể của một CanonicalCourse, thường được
mở dựa trên một học kỳ nào đó (AcademicSession). Nhưng không phải tất cả
CourseOffering nào cũng dựa trên một AcademicSession, vì có thể có những khóa
học dài hạn, không phục thuộc vào học kỳ.

CourseSet: Là tập hợp các CanonicalCourses và CourseOfferings của một ngành,


một khoa . Một CourseSet có thể chứa các CourseSet con khác.

Enrollment: Mô tả việc đăng ký, ghi danh của người học vào một khóa học nào đó.

Membership: Mô tả vai trò của một người trong một khóa học.

EnrollmentSet: Mô tả một bảng đăng ký học cùa học viên vào một khóa học

Section: Mô tả một nhóm học viên nhỏ trong một khóa học. Một nhóm có thể có các
nhóm nhỏ hơn. Một học viên có thể thuộc nhiều nhóm này trong một khóa học.

72
Hình 52 - Mô hình miền Sakai CMS

Trong thực tế có hai mô hình quản lý khóa học phổ biến

Mô hình đơn giản (Simple): Một khóa học có một trang web, sinh viên đăng ký vào
một khóa học (CourseOffering), không có nhóm (Section).

Hình 53 - Mô hình Simple

Mô hình phức tạp hơn (Large Lecture): Một khóa học có một trang web, trong đó có
nhiều nhóm nhỏ ứng với khóa học đó.

73
Hình 54 - Mô hình Large Lecture

.2.5.3 Hiện thực Sakai CMS.

API Course Management Service của Sakai cung cấp hai interface:

CourseManagementService là interface chỉ cho phép các component khác đọc


thông tin quản lý học.

CourseManagementAdministration: Đây là interface không bắt buộc hiện thực.


Nếu hiện thực thì nó làm nhiệm vụ cập nhật dữ liệu quản lý học.

.2.5.4 Demo.

Do không có mô hình thực của trường Đại học Nông Lâm, nên nhóm hiện thực lại
Sakai CMS dựa trên mô hình Simple: 1 khóa học có 1 site và không có nhóm nhỏ.

Với CSDL giả lập, dựa trên mô hình CSDL của Sakai, và thay đổi một vài chi tiết
cho đơn giản, phù hợp.

.2.6. Triển khai một ứng dụng viết thêm cho Sakai.
.2.6.1 Cài đặt một ứng dụng từ bên ngoài vào Sakai.
.2.6.1.1 Lưu ý.
Trước khi thêm các tool từ bên ngoài, chúng ta phải triển khai thành công
SakaiLMS từ source gốc của Sakai.

74
Ứng dụng nói đến ở đây có thể một ứng dụng web có giao diện cho người sử
dụng, ứng dụng này sau khi triển khai thành công thì có thể tìm thấy trong
SiteTool > Edit Tools của các course site hay project site của Sakai.

Ứng dụng cũng có thể chỉ ở phần model để hỗ trợ thêm cho Sakai, và người dùng
không thể nhìn thấy.

.2.6.1.2 Triển khai.


Thường thì các ứng dụng được viết thêm đều có hướng dẫn cài đặt cụ thể, nếu
không có các yêu cầu đặt biệt thì cách cài đặt chung như sau:

Do các ứng dụng viết cho Sakai thường là open source và được chia sẽ trên SVN
server. Do đó trước tiên ta download source code của ứng dụng bằng các chương
trình SVN client.

Chú ý phiên bản của ứng dụng cho phù hợp với Sakai đang sử dụng. Thường thì
link dạng */trunk là nơi lưu trữ phiên bản mới nhất, để tìm kiếm các phiên bản
cũ, thì bạn nên vào đường link */branches

Chú ý một số khác biệt giữa các phiên bản.

• Các ứng dụng cho Sakai 1.x, được build bằng Maven 1

• Các ứng dụng cho Sakai 2.x được build bằng Maven 2

o Kiễm tra tệp tin POM của ứng dụng.

Ví dụ:

<?xml version="1.0"?>

<project xmlns="http://maven.apache.org/POM/4.0.0">

<modelVersion>4.0.0</modelVersion>

<parent>

<artifactId>base</artifactId>

<groupId>org.sakaiproject</groupId>

<version>M2</version>

<relativePath>../pom.xml</relativePath>

</parent>

75

Nếu <version> là M2, 2.5.x, 2.4.x thì có thể dùng cho Sakai phiên bản 2.5.x, 2.4.x.

Nếu <version> là 2.6.0-SNAPSHOT, 2.7.0-SNAPSHOT.. thì dùng cho Sakai phiên


bản 2.6.x, 2.7.x …
Sau khi tải source code về, mở cửa sổ console cmd, trỏ đến thư mục source của
ứng dụng chạy dòng lệnh.

mvn clean install sakai:deploy

Trong lúc triển khai, chúng ta nên kết nối internet để Maven có thể tải các thư
viện mà ứng dụng yêu cầu (nếu có).

Sau khi triển khai thành công thì ứng dụng của chúng ta đã có thể sử dụng.

Lưu ý: đối với một số ứng dụng có yêu cầu đặc biệt thì chúng ta nên đọc tệp tin
hướng dẫn đi kèm source code để biết cách triển khai.

Ví dụ: Để triển khai ứng dụng sakai-scorm, thì đòi hỏi bạn phải build gói sakai-
wicket trước… Các triển khai của các gói cũng tương tự nhau.

.2.6.2 Viết một ứng dụng trong Sakai.


.2.6.2.1 Cài đặt plugin Sakai App Builder cho Eclipse.
• Cấu hinh Build Path cho project, tạo một Classpath Variables, tên M2_REPO
trỏ đến thư mục .M2 (đã tạo khi triển khai Sakai).

Ví dụ: C:\Documents and Settings\Administrator\.M2\repository.

Cài đặt plugin Sakai App Builder.

• Vào phần cài đặt plugin của Eclipse, chọn New Remote Site trỏ đến đường
dẫn http://source.sakaiproject.org/appbuilder/update/ rồi cài đặt.

.2.6.2.2 Tạo một webapp project với Sakai App Buider.


• Chọn File > New > Project > SakaiProject > Sakai App Project > Next

• Project Type: JSF (đây là framework thường dùng trong Sakai, dễ phát triển
và tương đối ổn định.).

• Implementation: Full CRUD App.

• Option: Testing và Entity Broker có thể bỏ qua

• Nhấn Finish.
76
Tốt hơn nên đọc file readme trong thư mục gốc của project trước khi sử dụng
project.

Cấu trúc một project trong Sakai được tạo từ plugin.

• Cấu trúc của project: tool > logic-api > logic-impl > dao-api > dao-impl.

• Mô hình kết nối: model > logic-api, dao-api, etc...

• Các dịch vụ liên quan kết nối: public-api > logic-api.

• Cấu trúc các file:

o app-name.

o api – tất cả lớp interface, model và các file hibernate hbm.

o src – bao gồm các interface, model và các file hbm.

o test - (có thể có) bao gồn các dữ liệu test có thể chia sẽ được với nhau.

o impl – nơi triển khai project.

o src – bao gồm src java cho tất cả các lớp triển khai của api.

o test – bao gồm tất cả các đơn vị và dữ liệu tích hợp cho test.

o pack – các thành phần của project mà Sakai hỗ trợ sẵn (có thể chỉ là
các tệp tin cấu hình spring).

o tool - project cho tool (giao diện người dùng).

o src – thư mục java src.

o java – bất kỳ mã code nào được dùng cho tool này.

o webapp.

o app-name – các file JSF.

o css – các file css.

o images – hình ảnh cần cho project.

o templates – các mẫu html của RSF.

o tools – chứa các file xml của Sakai tool.

77
o WEB-INF – các tệp tin cấu hình cho project (web.xml,
applicationContext.xml, v.v...

.2.6.3 Triển khai.


Sau khi phát triển tool, cách triển khai tương tự như cách triển khai một tool bên
ngoài Sakai đã nói ở trên.

Mở màn hình console cmd, trỏ đến thư mục ứng dụng, chạy lệnh:

mvn clean install sakai:deploy

78
Chương .3 Giới thiệu Portal – Liferay.
.3.1. Portal là gì?
Portal là cổng thông tin điện tử. Khác với các website thông thường portal là nơi tích
hợp hầu hết các thông tin và dịch vụ cần thiết cho người dùng. Sự ra đời của portal
nhằm giải quyết các nhược điểm mà các website thông thường mắc phải như khó
bảo trì, tích hợp, mờ rộng, v.v… đặc biệt là khả năng tùy biến khá cao, cá nhân hóa,
tính bảo mật cao và đăng nhập một .

Phân loại portal.

Tùy thuộc vào mục đích cung cấp dịch vụ cho người dùng cuối mà ta có những cổng
thông tin như sau:

− Cổng thông tin công cộng (Public portals): Khi muốn ghép nối các thông tin
lại với nhau từ nhiều nguồn, nhiều ứng dụng và từ nhiều người ta dùng loại
cổng thông tin này. Ngoài ra nó còn cho phép cá nhân hóa (personalization)
các website theo từng đối tượng người dùng. Ví dụ Yahoo.

− Cổng thông tin doanh nghiệp (Enterprise portal hay Corporate Desktops):
Cổng thông tin này được xây dựng để cho phép các thành viên của doanh
nghiệp sử dụng và tương tác trên các thông tin hay ứng dụng nghiệp vụ tác
nghiệp của doanh nghiệp.

− Cổng gáo dịch điện tử (Marketplace portals): Là nơi lien kết giữa người bán
và người mua. Ví dụ: eBay, ChemWeb.

− Cổng thông tin ứng dụng chuyên biệt (Specialized portals): Ví dụ như SAP
portal, cổng thông tin loại này cung cấp các ứng dụng chuyên biệt khác nhau.

Tính năng cơ bản

Các loại cổng thông tin đều có chung một số tính năng cơ bản. Người ta xem các
tính năng đó như một tiêu chuẩn để phân biệt portal với một website tổng hợp tin
tức, ứng dụng quản trị nội dung website, hoặc một ứng dụng chạy trên nền Web.

− Khả năng cá nhân hoá (Customization hay Personalization): Portal được hiển
thị theo nhiều cách khác nhau tùy thuộc vào đối tượng người dùng hay nhóm
người sử dụng. Mỗi cá nhân có thể tự chỉnh sửa cách thể hiện thông tin, ứng
dụng theo yêu cầu sử dụng.
− Tích hợp nhiều loại thông tin (Content aggregation): Cho phép xây dựng nội
dung thông tin từ nhiều nguồn khác nhau cho nhiều đối tượng sử dụng. Sự khác

79
biệt giữa các nội dung thông tin sẽ được xác định qua các ngữ cảnh hoạt động
của người dùng (user-specific context).
− Xuất bản thông tin( Content syndication): Thu thập thông tin từ nhiều nguồn
khác nhau, cung cấp cho người dùng thông qua các phương pháp hoặc giao thức
(protocol) một cách thích hợp. Có khả năng xuất bản thông tin với các định dạng
đã được quy chuẩn. Ngoài ra, các tiêu chuẩn dựa trên XML cũng phải được áp
dụng để quản trị và hiển thị nội dung một cách thống nhất, xuyên suốt trong quá
trình xuất bản thông tin.
− Hỗ trợ nhiều môi trường hiển thị thông tin (Multidevice support): Portal phải
có khả năng vận hành đa nền đa phương tiện. Để truy xuất vào portal người dùng
có thể sử dụng nhiều loại thiết bị như và nhiều trình duyệt khác nhau
− Khả năng đăng nhập một lần: Đây là một tính năng rất quan trọng. Portal sẽ lấy
thông tin về người sử dụng từ các thư mục như LDAP (Lightweight Directory
Access Protocol), DNS (Domain Name System) hoặc AD (Active Directory).
− Quản trị portal (Portal administration): Xác định cách thức hiển thị thông tin
cho người dùng cuối. Cho phép thiết lập các giao diện người dùng với các chi
tiết đồ hoạ, người quản trị phải định nghĩa được các thành phần thông tin, các
kênh tương tác với người sử dụng cuối, định nghĩa nhóm người dùng cùng với
các quyền truy cập và sử dụng thông tin khác nhau.
− Quản trị người dùng (Portal user management): Cung cấp các khả năng quản
trị người dùng cuối tùy vào đối tượng sử dụng của portal. Người sử dụng có thể
tự đăng ký thành viên tại một cổng thông tin công cộng hoặc được người quản trị
tạo tài khoản và gán quyền sử dụng thích hợp.

Nếu hệ thống chỉ thỏa mãn tối đa năm tính năng đã nêu trên thì đó chỉ là một ứng
dụng web hoặc phần mền quản trị nội dung chứ không phải giải pháp portal.

Nếu hệ thống không thỏa mãn tính năng Hỗ trợ nhiều môi trường hiển thị thông
tin (Multidevice support) nhưng lại thỏa mãn tất cả các tính năng còn lại thì hệ
thống đó vẫn được xem là giải pháp.

So sánh Portal và Web truyền thống.

Những ưu điểm nổi bật của Portal so với WebSite truyền thống là:

• Khả năng cá nhân hóa cao. Ví dụ: Giao diện portal có một số chức năng
không cần thiết với người dùng thì họ có thể bỏ đi, khả năng thay đổi cách
hiển thị của portal hoặc của từng porlet.

• Khả năng đăng nhập một lần với tất cả các tài nguyên liên kết với portal.

• Người dùng có thể truy cập thông tin từ nhiều thiết bị khác nhau.

• Người phát triển có thể dựa trên các chuẩn có sẵn để tích hợp công cụ mới.

80
.3.2. Giới thiệu về Liferay.
.3.2.1 Giới thiệu.
Hiện nay, việc xây dựng các cổng điện tử trên nền tản portal khá đa dạng ở Việt
Nam. Ví dụ Ủy ban nhân dân huyện Thanh Hóa (http://www.thanhhoa.gov.vn).
Liferay phù hợp để xây dựng và triển khai Cổng điện tử cho các đơn vị tỉnh thành,
bộ ngành, các tổ chức, doanh nghiệp, v.v…

Đến thời điểm tháng 06/2009 thì phiên bản mới nhất của Liferay là 5.2.3.

• Liferay Portal Enterprise Edition: Là phiên bản thương mại được hỗ trợ
nhiều tính năng.

• Liferay Portal Standard Edition: Là phiên bản miễn phí với các tính năng
mới nhất và hỗ trợ thông qua các hoạt động cộng đồng.

Liferay Portal đưa ra các chức năng vô cùng hữu ích với trên 60 ứng dụng theo
chuẩn JSR-168. Danh mục ứng dụng bao gồm: Quản trị, quản lý dữ liệu, cộng tác,
cộng đồng, giải trí, công cụ cá nhân, công cụ mua sắm, công cụ người phát triển.
Liferay được phát triển bằng ngôn ngữ lập trình Java trên nền tản J2EE và Web 2.0.
Liferay tương thích với 12 hệ quản trị cơ sở dữ liệu: Apache, Derby, IBM DB2,
Firebird, Hypersonic, Interbase, JDataBase, MySQL, Oracle, PostgresSQL, SAP,
SQL Server, Sybase. Cho phép hoạt động trên các hệ điều hành như Windows;
Linux: CentOS, RHES, SUSE, Ubuntu,v.v..; Unix: AIX, HP-UX, Mac OS X,
Solaris,v.v... Các công nghệ được sử dụng trong Liferay bao gồm: Apache
ServiceMix, Ehcache, Hibernate, ICEfaces, Java J2EE/JEE, jBPM, JGroups, jQuery
JavaScript Framework, Lucene, MuleSource ESB, PHP, Ruby, Seam, Spring &
AOP, Struts & Tiles, Tapestry, Velocity. Các tiêu chuẩn của Liferay hiện nay có:
AJAX, iCalendar & Microformat, JSR-168, JSR-127, JSR-170, JSR-286 (Portlet
2.0), JSF-314 (JSF 2.0), OpenSearch. Môi trường mở với hỗ trợ của web service
gồm có: JSON, Hessian, Burlap, REST, RMI, WSRP, WebDAV. Liferay hỗ trợ cho
22 ngôn ngữ với những bản dịch mặc định.

81
Liferay Portal là cổng thông tin cho phép người sử dụng kéo thả các ứng dụng để
sắp xếp phù hợp với sở thích của người sử dụng. Tất cả các trang của Liferay Portal
đều được thực hiện theo chuẩn CSS để đơn giản hóa việc phát triển giao diện. Sử
dụng một trong những hiệu ứng giao diện có sẵn để thay đổi bề ngoài của cổng
thông tin mà không phải thông qua bất kỳ thao tác chỉnh sửa mã nguồn phức tạp
nào. Liferay cho phép tạo và tích hợp giao diện vào hệ thống. Mỗi cá nhân trong
cộng đồng được cung cấp các trang cá nhân. Người sử dụng có thể thiết kế trang
riêng của theo sở thích. Hệ thống quản lí quyền sử dụng các ứng dụng trong Liferay
chặt chẽ, được chia làm nhiều cấp độ quản lí. Trong quá trình sử dụng ta cũng có thể
định nghĩa ra hệ thống người dùng cho hệ thống của mình.
Từ phiên bản 5.0, Liferay đã bắt đầu hổ trợ chuẩn JSR-286. Ngoài ra Liferay còn hỗ
trợ các JSP tag lib và nhiều class tiện ích khác trong những package khác nhau. Khi
sử dụng các package tiện ích này ta có thể dễ dàng phát triển portal hay portlet.
Nhưng các portlet không còn tuân theo chuần JSR-168. Liferay cũng cho phép thể
thêm các ứng dụng web viết bằng Struct, JSF, v.v… vào Liferay.

.3.2.2 Hướng dẫn Việt-hóa Liferay.


Bước 1: Tìm tệp tin Language_vi.properties, Language_vi.properties.native
trong portal-impl/src/content/

Bước 2: Chuyển đổi những từ sang tiếng Việt cho phù hợp.

Bước 3 : Deploy.

− Dùng công cụ Ant ,chọn Add Buildfiles, chọn file build.xml của Liferay
source. Lúc này ta ở cửa sổ Ant sẽ có 2 thư mục như sau: Portal, portal_impl

− Chọn portal_impl rồi nhấn vào build-lang. Nhận được thông báo như sau:
BUILD SUCCESSFUL.

− Sau đó nhấn vào deploy. Nếu thành công sẽ nhận được thông báo như sau:
BUILD SUCCESSFUL thì việc việt hóa Liferay đã thành công.

.3.2.3 Tạo theme mới cho Liferay.


Cách dễ dàng nhất để tạo theme là lấy một theme làm mẫu sau đó sửa đổi các tệp tin
.css sao cho phù hợp với nhu cầu sử dụng.Theme có thể thêm vào Liferay bằng hai
cách.

.3.2.3.1 Thêm tệp tin và thư mục


Theme được thêm vào Liferay bằng cách chép một cấu trúc thư mục tuân theo quy
định. .Một theme thường có cấu trúc thư mục sao đây:

82
Hình 55 - Tạo theme mới cho Liferay - Cấu trúc thư mục theme

Css: Chứa những tệp tin css, có nhiệm vụ định kiểu hiển thị cho các thành phần của
hệ thống FIT portal.

Images: Chứa các image của theme, được dùng hoặc tham chiếu bởi những
template.

Javascript: Chứa tệp tin js với nhiệm vụ giúp load các porlet lên portal.

Templates: Chứa những template về cái nhìn tổng quan của porlet, popup.

WEB-INF: Tệp tin Liferay-look-and-feel.xml trong thư mục này có tác dụng đăng
kí theme cho Liferay.

.3.2.3.2 Đóng gói theme thành file war.


Ta có thể đóng gói một theme hay một tập các themes vào trong một tệp tin WAR.
Tệp tin này có thể được deploy để cài đặt trong Liferay. Tập hợp các tệp tin được
đóng gói tuân theo quy luật như cách tạo theme đã trình bày ở trên.

Đề tạo thành một tệp tin WAR, ta dùng lệnh JAR cho toàn thư mục. Ví dụ:

Chạy lệnh sau trong cửa sổ cmd: C:\CreateTheme\greentheme> jar cvf


greentheme.war *.*

.3.2.4 Chuyển 1 ứng dụng web thành portlet.


.3.2.4.1 Đặt vấn đề.
Việc phát triển một portlet từ đầu đến cuối theo chuẩn JSR-168 để tích hợp vào
portal không phải là một vấn đề phức tạp. Nhưng nếu bạn có một ứng dụng web đã
phát triển trước đó, nay muốn tích hợp vào portal thì như thế nào? Khi đó bạn cần
nghĩ đến portals bridges.

.3.2.4.2 Các portals bridges.


Trên trang web http://portals.apache.org/bridges/download.html của Apache, có hỗ
trợ một số bridge chuyển thành các portlet:

• JSF portlet

83
• Struts portlet

• PHP portlet

• Perl portlet

.3.2.4.3 Thư viện.


Tải về tại http://portals.apache.org/bridges/download.html

Giải nén, trong thư mục jars (tùy phiên bản có thể là thư mục khác), chọn các tệp
tin:

• portals-bridges-frameworks

• portals-bridges-jsf

• portals-bridges-common

Chép vào thư mục WEB-INF/lib của JSF project.

Tiếp theo tạo file portlet.xml trong thư mục WEB-INF của project.

84
.3.2.4.4 portlet.xml
<?xml version="1.0" encoding="UTF-8"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
version="1.0"> Đặt tên cho portlet,
và display của nó
<portlet>
<description>Student Management JSF application</description>
<portlet-name>jsfStudentManagement</portlet-name>
<display-name>JSF Student Management</display-name>
<!-- You must use this Portlet implementation class -->
<portlet-class>org.apache.portals.bridges.jsf.FacesPortlet</portlet-class>
Phải đặt đúng như vậy
<init-param>
<description>Portlet init view page</description>
<name>ViewPage</name>
<value>/index.jsp</value>
</init-param>
Đặt ViewPage, EditPage,
<supports> HelpPage cho các mode
<mime-type>text/html</mime-type> tương ứng.
<portlet-mode>VIEW</portlet-mode>
<portlet-mode>EDIT</portlet-mode> Value là trang *. jsp, *.do
<portlet-mode>HELP</portlet-mode> … bắt đầu của ứng dụng,
</supports> theo mode tương ứng.
<portlet-info>
<title>Student Management</title>
<short-title>Student Management</short-title>
</portlet-info>

</portlet> </portlet-app>

.3.2.4.5 Pages.
Bỏ hết các thẻ của html như <html>, <head>, <body>.., chỉ để lại những nội dung
trong body.

.3.2.4.6 File liferay-portlet.xml


<?xml version="1.0"?>
<!DOCTYPE liferay-portlet-app PUBLIC "-//Liferay//DTD Portlet Application 4.4.0//EN"
"http://www.liferay.com/dtd/liferay-portlet-app_4_4_0.dtd">

<liferay-portlet-app>
<portlet>
<portlet-name>portlet_name</portlet-name>
</portlet>
</liferay-portlet-app>

85
.3.2.4.7 File liferay-display.xml
<?xml version="1.0"?>
<!DOCTYPE display PUBLIC "-//Liferay//DTD Display 4.0.0//EN" "http://www.liferay.com/dtd/liferay-
display_4_0_0.dtd">

<display>
<category name="category_name">
<portlet id="portlet_name" />
</category>
</display>

.3.2.4.8 Application bằng JSF đã được chuyển đổi


 Tìm kiếm nhanh thời khóa biểu:

o Mục đích: Nhằm giúp sinh viên tìm nhanh ra thời khóa biểu của một
lớp học nào đó.

Ngoài ra ứng dụng này có có các chức năng thêm, xóa, sửa. Tùy thuộc vào từng đối
tượng người dùng mà các thao tác trên ứng dụng có được thực hiện hay không.

Hình 56 - Portlet Tìm kiếm nhanh thời khóa biểu

.3.2.5Quản lí nội dung với CMS.


.3.2.5.1 Tổng quan về CMS.
Content Management System là cụm từ được viết đầy đủ của CMS được gọi là hệ
quản trị nội dung hay hệ thống quản trị nội dung. Đây là phần mềm để tổ chức và
tạo ra môi trường thuận lợi nhằm mục đích xây dựng hệ thống tài liệu và các loại nội
dụng khác một cách thống nhất. Năm 2002, công ty Microsoft mới bắt đầu tham gia
lĩnh vực này. Số lượng các công ty ở Việt Nam xây dựng và sử dụng các hệ thống
CMS khá giới hạn. Phần lớn các công ty phát triển các hệ thống CMS đều với mục
đích kinh doanh. Nhưng bên cạnh đó cũng có một số những công ty, tổ chức và cá
nhân cung cấp các giải pháp CMS dưới dạng mã nguồn mở hay miễn phí. Các công
nghệ sử dụng cho hệ thống CMS rất đa dạng:

• Java: CMS Genie, CMS Master, Cofax, Contelligent, Daisy, Eplica, …


86
• Java Script: CMS Master, Complete Site Manager, Open CMS…
• PHP: Acuity CMS, AGPCMS, Back-End CMS, Complete Site Manager, …
• C++: Lighthouse, Manila…
• ASP: Acuity CMS, Baseline CMS…
• Cold Fusion: AssetNow, EasyConsole CMS…
• ASP.NET: AxCMS.net, Composite CMS, contentXXL - ASP.NET CMS, …
• VB.NET: ContentXXL - ASP.NET CMS, Dozing Dogs ASP.NET CMS, …
• C#: ContentXXL - ASP.NET CMS, Rainbow…
• Python: Easy Publisher…

.3.2.5.2 Lợi ích từ việc sử dụng CMS.


− Cập nhập thông tin nhanh chóng. Nhờ đó ta có thể giảm được thời gian, công
sức và chi phí cho việc cập nhập thông tin.

− Các ứng dụng khác có thể sử dụng CMS như một công cụ hỗ trợ cho việc
cung cấp và cập nhập thông tin.

− CMS giúp người sử dụng dễ dàng tạo ra nội dung các trang web.

− Phân quyền sử dụng tương ứng với mỗi đối tượng sử dụng.

− Cá nhân hóa thông tin người dùng.

− Cung cấp cơ chế tìm kiếm thông tin.

− Cho phép dùng các template nhằm hỗ trợ tạo ra nội dung một cách đồng
nhất.

− Cho phép thay đổi cách thức hiển thị của các trang web trong Website.

− CMS còn giúp chấm dứt tình trạng thông tin thiếu cập nhập trên các Website.

.3.2.5.3 CMS trong Liferay.


Liferay Portal cung cấp hai chức năng chính trong CMS: Quản lý nội dung và xuất
bản các nội dung đó.

Quản lý dữ liệu: Việc quản lý dữ liệu được cung cấp qua các portlet Document
Library, Image Gallery. Document Library để quản lý tất cả hình ảnh trong hệ
thống. Còn Image Gallery dùng để quản lý các tập tin.

87
Xuất bản nội dung: Web Content Display là porlet cho phép người dùng tạo, chỉnh
sửa và xuất bản các nội dung cần hiển thị. Trong porlet này ta có thể tạo ra các mẫu
template có sẵn để định dạng cho nội dung cần hiển thị, cho phép nội dung được tạo
được phép tìm kiếm với porlet Web Content Search hay không, nhóm nội dung vào
các Tags hay Category để để dàng cho việc xuất bản với porlet Assert Publisher.
Porlet Assert Publisher là công cụ cho phép ta hiển thị đồng loạt các nội dung trong
porlet Web Content Display theo Tags. Nội dung trong porlet Assert Pulisher được
hiển thị một cách linh động và tự động cập nhập nếu được thiết lập.

Ngoài ra Liferay CMS còn có các chức năng sau: Upload được nhiều định dạng tệp
tin vào hệ thống. Hỗ trợ 22 ngôn ngữ và cho phép định nghĩa thêm các ngôn ngữ
khác. Tìm kiếm nội dung trong hệ thống nhanh chóng qua porlet Web Content
Search. Với porlet Navigation ta sẽ nhận được cây thư mục liên kết đến các trang
của portal trong cùng một Community hay Organigation. SiteMap là porlet có khả
nay hiển thị liên kết linh động hơn nhiều so với Navigation. Việc hiệu chỉnh style
của các porlet kể trên hết sức dễ dàng qua công cụ Look and Feel tương ứng với
từng porlet hay từng loại porlet.

88
Chương .4 Xây dựng FIT Portal dựa trên Liferay Portal.
.4.1.1 Giới thiệu.
FIT Portal được xây dựng trên cơ sở về cấu trúc và nội dung của khoa Công Nghệ
Thông Tin trường Đại học Nông Lâm. Hệ thống này có thể dễ dàng mở rộng thành
hệ thống của trường Đại học Nông Lâm.

.4.1.2 Các vai trò (role), hệ thống người dùng sẵn có trong Liferay
Người dùng không đăng ký được gọi là khách (Guest), không có role.

Người dùng đã đăng ký có một trong các role cơ bản sau:

− User: Người dùng đăng ký tài khoản trong Liferay, không có tài nguyên
riêng.

− Power User: Có trang web trong hệ thống dành cho cá nhân người dùng dạng
này, bao gồm trang công cộng và trang riêng (public pages và private pages).

− Owner: Người người dùng đã đăng ký và là người tạo ra một tài nguyên nào
đó (trang web, file…).

− Administrator: Quản trị hệ thống.

Ngoài ra người dùng có thể tham gia vào một hay nhiều nhóm người dùng sau:

− User group: Nhóm các người dùng có chung đặc điểm nào đó, có trang web
riêng. Các người dùng trong nhóm có vai trò như nhau.

− Organization: Nhóm các người dùng, các nhóm người dùng có chung đặc
điểm nào đó, có trang web riêng, tài nguyên riêng. Người dùng trong tổ chức
này có vai trò sau:

o Organization Owner: Người tạo ra tổ chức.

o Organization Administrator: Người quản trị tổ chức.

o Organization Member: Thành viên trong tổ chức.

− Community: tập hợp các người dùng, các nhóm người dùng, các tổ chức, có
trang web riêng và tài nguyên riêng. Người dùng trong cộng đồng này có các
vai trò sau:

o Community Owner: Người tạo ra cộng đồng.

89
o Community Administrator: Người quản trị cộng đồng.

o Community Member: Thành viên trong cộng đồng.

− Hai khái niệm Organization và Community gần giống như nhau. Việc quyết
định sử dụng khái niệm nào để quản lý một hệ thống phụ thuộc vào sự phân
tích của người phát triển.

− Trong Liferay, mặc định người dùng đăng ký vào hệ thống đều thuộc cộng
đồng khách (Community Guest) và đương nhiên có thể truy cập vào các tài
nguyên của khách.

.4.1.3 Các role, hệ thống người dùng xây dựng thêm trong FIT portal.
.4.1.3.1 Role.
− Student: Dành cho đối tượng người dùng là sinh viên.

o Được phép gửi luồng mới trên các chuyên mục, trả lời trong Diễn đàn.

− Instructor: Dành cho đối tượng người dùng là giảng viên.

o Được phép gửi luồng mới trên các chuyên mục, trả lời trong Diễn đàn.

o Có trang web trong hệ thống dành cho Instructor.

− CMSContributor: Là người chỉ được phép viết bài, mẫu tin để đăng trên hệ
thống FIT portal, không được quyền duyệt bài viết đó. Người này chỉ được
quyền sửa bài của họ trước khi CMSAdmin duyệt bài viết đó. Sau khi mẫu tin
được duyệt, CMSContributor không được sửa đổi.

− CMSEditor: Là người được phép viết bài, mẫu tin để đăng trên hệ thống FIT
portal, hiệu chỉnh những bài viết chưa được duyệt nhưng không được quyền
approve bài viết đó.Sau khi bài viết của đối tượng này được duyệt thì họ vẫn
có quyền sửa đổi nội dung. Đồng thời đối tượng này còn được phép tạo thông
báo cho tất cả các người dùng thuộc role là Student và Intructor.

− CMSAdmin: Là người được phép viết bài, mẫu để đăng trên hệ thống FIT
portal, hiệu chỉnh những bài viết chưa được duyệt và duyệt chúng; xóa tất cả
các bài viết, mẫu tin trong hệ thống. Đồng thời đối tượng này còn được phép
tạo thông báo cho tất cả các người dùng thuộc role là Student và Intructor.
Bên cạnh đó người dùng thuộc role này còn được quyền kiểm soát tất cả các
hoạt động của diễn đàn.

90
.4.1.3.2 User group.
Student_Group: Để nhóm các sinh viên. Sinh viên trong nhóm này được phép gửi
luồng mới trong các chuyên mục, trả lời trong Diễn đàn.

Instructor_Group: để nhóm các giảng viên. Giảng viên trong nhóm này được phép
gửi luồng mới trong các chuyên mục, trả lời trong Diễn đàn và có trang web riêng.

.4.1.4 Đối tượng người dùng trong hệ thống FIT portal.


Hệ thống có năm loại người dùng chính:

• Người dùng khách.

• Sinh viên.

• Giảng viên.

• CMSAdmin.

• Admin.

Người dùng khách: Là những người dùng truy xuất portal mà không đăng ký, chỉ
có quyền truy xuất các tài nguyên công cộng của người dùng đã đăng ký, của cộng
đồng, tổ chức.Người dùng khách có role là Guest. Người dùng khách chỉ được phép
truy cập nhóm trang sau:

• Trang chủ: Chứa hình ảnh liên kết, WebSite liên kết của Giảng viên, thông
báo dành cho tất cả mọi người, năm tin tức mới nhất và các liên kết khác.

• Giới thiệu: Giới thiệu về khoa Công nghệ thông tin trường Đại học Nông
Lâm với các nội dung như giới thiệu chung, đào tạo, tổ chức.

• Đào tạo: Thông tin về chương trình đào tạo, chuyên ngành đào tạo và hệ đào
tạo của khoa Công nghệ thông tin trường Đại học Nông Lâm.

• Sinh Viên: Người dùng khách có thể xem danh sách sinh viên của tất cả các
lớp thuộc khoa. Danh sách của sinh viên sẽ hiển thị mã số sinh viên, tên sinh
viên. Và các thông tin sau thời khóa biểu, lịch thi, điểm thi, công đoàn, đoàn

91
thanh niên Việt Nam, xem thông tin về việc làm, mẫu đơn (không được tải
mẫu đơn), và sử dụng chức năng tìm nhanh thời khóa biểu.

• Nghiên cứu: Người khách dùng sẽ biết được thông tin về việc nghiên cứu của
khoa: Đề tài cấp trường, cấp bộ, cấp Nhà nước; các bài báo khoa học; đề tài
tốt nghiệp của sinh viên thuộc khoa. Ngoài ra còn có thư viện khoa với giáo
trình, slice bài giảng; sách; sách điện từ thuộc khoa. Người khách dùng không
được tải bất kì nội dung nào từ hệ thống.

• Sơ đồ trang: Sơ đồ cấu trúc toàn bộ hệ thống FIT Portal.

• Diễn đàn: Người dùng khách chỉ có thể xem được nội dung thảo luận của
diễn đàn, không thể thực hiện bất kì thao tác nào.

Sinh viên: Là sinh viên của khoa Công nghệ thông tin. Sinh viên có role: User,
Student, CMSContributor. Sinh viên thuộc User Group: Student_Group. Sinh viên
thuộc Community: Guest.

• Sinh viên được phép truy cập vào tất cả các trang mà người dùng khách có
thể truy cập được.Đối với phần “Thông báo” thuộc Trang chủ sinh viên sẽ
nhận được những thông báo dành riêng cho sinh viên.

• Ngoài ra sinh viên còn phép gửi luồng mới trong các chuyên mục, trả lời
trong Diễn đàn của Khoa công nghệ thông tin.

• Một số sinh viên sẽ được cấp quyền viết bài để đăng trên hệ thống FIT portal
nhưng bài viết đó không thể hiển thị ngay trên hệ thống mà cần sự duyệt qua
của các đối tượng có role là CMSEditor và CMSAdmin.

Giảng viên: Là cán bộ, giảng viên của khoa Công nghệ thông tin. Giảng viên có
role: User, Power User, Instructor, CMSEditor. Giảng viên thuộc User Group:
Instructor_Group. Giảng viên thuộc Community: Guest.

92
• Mỗi giảng viên sẽ có trang riêng cho mình. Giảng viên có thể sử dụng trang
web này để viết blog, đăng các thông báo, quản lý lịch làm việc… Giảng viên
được quyền thiết kế những trang này bằng những công cụ được phép.

• Giảng viên được phép truy cập vào tất cả những khu vực mà sinh viên được
phép. Có tất cả các quyền mà sinh viên được cấp như gửi luồng mới trong các
chuyên mục, trả lời trong Diễn đàn của Khoa công nghệ thông tin.

• Đối với phần “Thông báo” của Trang chủ giảng viên sẽ nhận được những
thông báo dành riêng cho giảng viên. Đồng thời giảng viên còn được tạo và
sửa thông báo cho các đối tượng người dùng là Sinh viên, Giảng viên

• Tất cả giảng viên đều được quyền viết bài để đăng trên hệ thống FIT portal,
đồng thời chỉnh sửa những bài viết chưa được approve, nhưng không có
quyền làm cho nó hiển thị trên hệ thống và cần có sự duyệt qua của
CMSAdmin.

CMSAdmin: Người phụ trách cập nhật thông tin cho trang web dành cho khách.
CMSAdmin có role: User, CMAdmin. CMSAdmin thuộc Community: Guest.

• CMSAdmin chỉ được phép thêm, chỉnh sửa, xóa nội dung của các trang:
Trang chủ, giới thiệu, thông báo, tổ chức, thời khóa biểu, sinh viên, đoàn thể,
thư viện khoa, nghiên cứu, mẫu đơn, hợp tác. Và quản lý thư viện ảnh, thư
viện tài liệu của hệ thống.Ngoài ra CMSAdmin còn được quyền approve các
bài viết chưa được approve nhằm giúp chúng hiển thị trên hệ thống FIT
portal.

• Tạo thông báo cho các đối tượng người dùng là Sinh Viên và Giảng Viên

• CMSAdmin còn được quyền quản lý diễn đàn.

Admin: Quản trị hệ thống Web Site của khoa Công nghệ thông tin. Admin có role:
User, Power User, Administrator. Admin thuộc Community: Guest. Đây là đối
tượng có quyền cao nhất trong hệ thống, có thể thực hiện tất cả các chức năng, tất cả

93
các hành động thuộc Web Site. Chức năng chủ yếu của Admin trong hệ thống này là
quản lý người dùng, cấp phát quyền truy cập (cấp phát role).

Hình 57 - Sơ đồ khái quát về hệ thống người dùng của WebSite

.4.1.5 Quy trình tạo mẫu tin của hệ thống FIT portal.
Quy tắc hoạt động: Một số sinh viên sẽ được cấp quyền CMSContributor thì được
tạo tin tức cho hệ thống FIT portal, sinh viên chỉ được quyền sửa mẫu tin của họ
trước khi mẫu tin được duyệt. Tất cả các giáo viên đều được quyền tạo mẫu tin và
sửa chữa mẫu tin của họ; đồng thời họ còn sửa được tất cả các mẫu tin do đối tượng
sinh viên tạo ra .Tất cả các CMSAdmin đều được quyền tạo mẫu tin, sửa chữa tất cả
các mẫu tin và duyệt mẫu tin. Tất cả các tin tức được duyệt đều được hiển thị trên
hệ thống FIT portal.

Ghi chú: Sau khi sinh viên có role là CMSContributor tạo một bài viết bất kì,
CMSAdmin chỉ định quyền chỉnh sửa bài viết đó cho các đối tượng có role là
CMSEditor. Và cũng chính CMSAdmin sẽ hủy bỏ quyền sửa chữa bài viết của sinh
viên đó sau khi bài viết đó được duyệt.

Hệ thống tin tức nội dung hiển thị tin tức trên các trang web thuộc hệ thống FIT
portal được mô tả theo một quy trình như hình sau:

94
Hình 58 - Quy trình tạo mẫu tin của hệ thống FIT portal

.4.1.6 Cài đặt các trang trong hệ thống.


Cấu trúc trang được tổ chức trong hệ thống FIT Portal:

95
Hình 59 - Cấu trúc trang

Các trang trong hệ thống sẽ được nhóm lại với nhau theo chủ đề trong đó có các
trang chính sau: Trang chủ, Giới thiệu, Đào tạo, Nghiên cứu, Sơ đồ trang, Quản lý
dữ liệu, Diễn đàn, và link liên kết đến WebSite Học trực tuyến. Với nhóm trang
Giới thiệu thì bao gồm các trang Giới thiệu chung, Tổ chức, Hợp tác. Nhóm trang
Đào tạo bao gồm trang Chương trình đào tạo, Chuyên ngành đào tạo, Hệ đào tạo.
Còn với nhóm trang Sinh viên thì bao gồm các trang Mẫu đơn, Việc làm và ba nhóm
trang là Danh sách sinh viên, Đoàn thể, Thời khóa biểu.

96
.4.1.6.1 Trang chủ:
Với mục đích hiển thị liên kết đến các trang thuộc Website, và hiển thị tin tức về
công nghệ thông tin. Các porlet được sử dụng:

− Mười porlet WebContent Display (Số 1, 3, 5, 7, 9, 11, 12, 13, 14, 16) để hiển
thị các banner, hình ảnh để liên kết, giới thiệu về cơ hội việc làm và du học
của sinh viên thuộc khoa và liên kết đến WebSite của tất cả các giảng viên
thuộc khoa Công nghệ thông tin.

− Năm porlet SiteMap (Số 2, 4, 6, 8, 10): để điều hướng trang. Là menu để liên
kết đến các trang thuộc khoa Công nghệ thông tin

− Một porlet Announcement (Số 15): Có chức năng thông báo cho tất cả các
đối tượng người dùng truy cập vào hệ thống. Tùy thuộc vào đối tượng người
dùng mà các thông báo sẽ khác nhau.

− Một porlet Asset Publisher (Số 17): Hiển thị năm tin tức mới nhất của hệ
thống FIT Portal.

97
Hình 60 - Trang chủ

.4.1.6.2 Giới thiệu.


Nhóm trang Giới Thiệu bao gồm ba trang là Giới thiệu chung, Tổ chức và Hợp tác.
Ba trang này bao gồm các porlet giống nhau. Do đó ta lấy trang Tổ chức để phân
tích cấu trúc trang của chúng. Trang này bao gồm:

− Ba porlet WebContent Display (Số 1, 3, 4) để hiển thị các banner và nội dung
trang Tổ chức.

− Một porlet SiteMap (Số 2): Để điều hướng trang. Là menu để liên kết đến các
trang còn lại của nhóm trang Giới thiệu.

98
Hình 61 - Trang Sơ đồ tỗ chức khoa Công Nghệ Thông Tin

Nhóm trang Đào tạo bao gồm 3 trang là Chương trình đào tạo, Chuyên ngành đào
tạo và Hệ đào tạo. Ba trang này bao gồm các porlet giống nhau. Do đó ta lấy trang
Chương trình đào tạo để phân tích cấu trúc trang của chúng. Trang này bao gồm:

− Ba porlet WebContent Display (Số 1, 3, 4) để hiển thị các banner và nội dung
trang Chương trình đào tạo.

− Một porlet SiteMap (Số 2): Để điều hướng trang. Là menu để liên kết đến các
trang còn lại của nhóm trang Đào tạo.

Hình 62 - Trang Chương trình đào tạo

.4.1.6.3 Sinh viên.


Sinh viên bao gồm ba nhóm trang: Danh sách sinh viên, Đoàn thể, Thời khóa biểu
và hai trang là Mẫu Đon và Việc làm.

99
Hình 63 - Cấu trúc trang cho Sinh viên

Danh sách sinh viên

Các đối tượng sử dụng sẽ xem được danh sách sinh viên thuộc khoa công
nghệ thông tin. Danh sách sinh viên sẽ được liệt kê theo thứ tự: Sinh viên đại học,
sinh viên cao đẳng, trung cấp và tại chức. Khi người dùng truy cập vào nhóm trang
Sinh viên thì mặt định trang chính là danh sách sinh viên đại học.

Chọn trang danh sách sinh viên đại học để phân tích, ta có các porlet sau.

− Sáu porlet WebContent Display (Số 1, 3, 5, 7, 9, 11) để hiển thị các banner.

− Năm porlet SiteMap (Số 2, 4, 6, 8,10): Để liên kết đến các trang thuộc nhóm
trang Sinh Viên.

− Một porlet Asset Publisher (Số 12): Để hiển thị danh sách sinh viên.

100
Hình 64 - Trang hiển thị danh sách sinh viên đại học

Các trang hiển thị danh sách sinh viên cao đẳng, trung cấp, tại chức có cấu trúc tổ
chức porlet trong như trang hiển thi danh sách sinh viên đại học.

Đoàn thể.

Công tác đoàn thể của khoa sẽ được thông báo ở đây. Trong nhóm trang này còn có
Ba trang con là: Công đoàn, Đoàn thanh niên, Hội học sinh.Chúng có cấu trúc giống
như nhau. Do đó ta chỉ cần phân tích trang Công Đoàn. Bao gốm:

− Sáu porlet WebContent Display (Số 1, 3, 5, 7, 9, 11) để hiển thị các banner
một porlet.

− Năm porlet SiteMap (Số 2, 4, 6, 8, 10): Để liên kết đến các trang thuộc nhóm
trang Sinh Viên.

− Một porlet Asset Publisher (Số 12): Để hiển thị danh sách thông tin về hoạt
động của công đoàn.

101
Hình 65 - Trang đoàn thể

Thời khóa biểu.

Thời khóa biểu của tất cả các lớp học thuộc khoa Công nghệ thông tin trường Đại
học Nông Lâm bao gồm các hệ : đĐại học, cao đẳng, đại học, tại chức. Gốm có:

− Sáu porlet WebContent Display (Số 1, 3, 5, 7, 9, 11) để hiển thị các banner

− Năm porlet SiteMap (Số 2, 4, 6, 8,10): Để liên kết đến các trang thuộc nhóm
trang Sinh Viên.

− Một porlet Asset Publisher (Số 12): Để hiển thị thời quá biểu.

102
Hình 66 - Trang thời khóa biểu

Ở trang thời khóa biểu có các liên kết là: Tìm nhành thời khóa biểu, lịch thi, điểm
thi.

− Tìm nhanh thời khóa biểu: Chứa thời khóa biểu của các lớp thuộc khoa công
nghệ thông tin, giúp cac đối tượng người dùng nhanh chóng tìm được thời
quá biểu theo từng lớp.

− Lịch thi: Chứa lịch thi của các lớp thuộc khoa Công nghệ thông tin.

− Điểm thi: Chứa điểm thi của các lớp thuộc khoa công nghệ thông tin.

Cấu trúc tổ chức của hai trang Lịch thi, Điểm thi với trang Thời khóa biểu là hoàn
toàn giống nhau. Riêng trang Tìm nhanh thời khóa biểu thì có sự thay đổi chút ít
trong loại porlet sử dụng. Các porlet được sử dụng trong trang đó là:

− Sáu porlet WebContent Display ( Số 1, 3, 5, 7, 9, 11) để hiển thị các banner.

− Năm porlet SiteMap (Số 2, 4, 6, 8, 10): Để liên kết đến các trang thuộc nhóm
trang Sinh Viên.

− Một porlet Quich Schedule (Số 12): Để hiển thị chức năng tìm kiếm nhanh
thời khóa biểu với tên lớp.

103
Hình 67 - Trang tìm nhanh Thời khóa biểu

Nghiên cứu.

Mục đích của nhóm trang nghiên cứu là khi truy cập vào trang này người dùng
khách sẽ truy cập được các thông tin sau: Các đề tài cấp trường, cấp Bộ, cấp Nhà
Nước; các bài báo khoa học; đề tài tốt nghiệp của sinh viên và thư viên khoa. Trong
thư viện khoa bao gồm các thông tin sau: giáo trình, slice bài giàng; sách; sách điện
tử. Tất cả các trang thuộc trang này đều tạo nên từ các porlet: WebContent Display,
SiteMap và Asset Publisher.

Hình 68 - Trang Nghiên cứu

Lấy trang đề tài cấp trường, cấp Bộ, cấp Nhà Nước đề phân tích các porlet của trang:

− Hai porlet WebContent Display (Số 1, 3) để hiển thị các banner.

− Một porlet SiteMap (Số 2): Để liên kết đến các trang thuộc nhóm Nghiên
cứu.
104
− Một porlet Asset Publisher (Số 12): Để hiển thị các đề tài cấp trường, cấp Bộ,
cấp Nhà Nước.

Mẫu đơn.

Mẫu đơn là trang chứa những mẫu đơn thông dụng. Dùng hai loại porlet:

− Mười hai porlet WebContent Display (Số 1, 3, 5, 7, 9, 11, 12) để hiển thị các
banner và các mẫu đơn thông dụng.

− Năm porlet SiteMap (Số 2, 4, 6, 8, 10): Để liên kết đến các trang thuộc nhóm
trang Sinh Viên.

Hình 69 - Trang Mẫu đơn

.4.1.6.4 Sơ đồ trang.
Trang này có chức năng giúp các đối tượng người dùng biết được sơ đồ các trang
thuộc hệ thông FIT portal.Có hai porlet được sử dụng :

− Một porlet WebContent Display (Số 1) để hiển thị các banner.

− Một porlet SiteMap(Số 2): Hiển thị các liên kết chính của hệ thống FIT portal

105
Hình 70 - Trang Sơ đồ trang

.4.1.6.5 Diễn đàn.


Trang này có hai porlet là Web Content Display (Số 1) và Message Board (Số 2):

Hình 71 - Trang Diễn đàn

.4.1.6.6 Quản lý dữ liệu.


Đây là nhóm trang chỉ có CMSAdmin và Admin thấy được và thao tác được. Nhóm
này nhằm giúp hai đối tượng này quản lý được thư viện tài liệu và hình ảnh của hệ
thống, và thêm dữ liệu về thời khóa biểu nhằm phục việc tìm kiếm thời khóa biểu
của các đối tượng người dùng.

Trước tiên ta phân tích trang Thêm thời khóa biểu, trang này có bốn loại porlet sau:

− Hai porlet WebContent Display ( Số 1, 3) để hiển thị các banner.

106
− Một porlet SiteMap (Số 2): Để hiển thị các liên kết của nhóm trang Quản lý
dữ liệu.

− Một porlet Quick Schedule Admin: Để thêm, xóa, sửa thời khóa biểu.

Hình 72 - Trang thêm thời khóa biểu

Còn ở trang quản lý thư viện tài liệu cũng có bốn loại porlet là:

− Hai porlet WebContent Display ( Số 1, 3) để hiển thị các banner.

− Một porlet SiteMap (Số 2): Để hiển thị các liên kết của nhóm trang Quản lý
dữ liệu.

− Một porlet Thư viện tài liệu.

Và ở trang quản lý thư việc ảnh có bốn porlet là:

− Hai porlet WebContent Display ( Số 1, 3) để hiển thị các banner.

− Một porlet SiteMap (Số 2): Để hiển thị các liên kết của nhóm trang Quản lý
dữ liệu.

− Một porlet Thư viện ảnh.

107
Hình 73 - Trang quản lý tài liệu

Hình 74 - Trang quản lý hình ảnh

.4.1.6.7 Trang riêng của giảng viên.


Tất cả các giảng viên đều có trang web cá nhân riêng. Ban đầu tất cả các website cá
nhân của giảng viên đều theo một template sẵn. Sau đó các giảng viên có thể tùy
biến theo sở thích. Cấu trúc trang của giảng viên sẽ như sau:

108
Hình 75 - Cấu trúc trang của các Website cá nhân của giảng viên

Giảng viên được quyền thêm mới các porlet có trong hệ thông nhưng với mức độ
hạn chế. Những porlet giảng viên được quyền sử dụng:

Hình 76 - Công cụ cho giảng viên

Hệ thống website của khoa công Nghệ thông tin dễ dàng mở rộng thành hệ thống
WebSite của trường Đại học Nông Lâm

Hệ thống phân quyền sẽ được thiết lập theo tổ chức.Tạo role với loại là tổ chức. Khi
đó thành viên của website chỉ có thể hoạt động trong tổ chức của nó. Ví dụ ta tạo 1
role tên là Student Organizations với loại là tổ chức. Hệ thống có hai tổ chức

109
(Organizations) là A và B, thì lúc này một người nào đó là thành viên mang role
Student Organizations và là thành viên của tổ chức A. Thì nó chỉ có thể có tham gia
những hoạt động thuộc tổ chức A, còn bên tổ chức B nó sẽ bị hạn chế.

Trong Liferay, mặc định người dùng đăng ký vào hệ thống đều thuộc cộng đồng
khách (Community Guest) và đương nhiên có thể truy cập vào các tài nguyên của
khách.Đồng thời người dùng khách cũng được quyền truy xuất vào hệ thống nếu
được phép. Do đó ta chọn Community Guest làm website của trường đại học Nông
Lâm. Hệ thống website của trường được xây dựng dựa trên cấu trúc của trang web
trường đại học Nông Lâm hiện nay.Sơ đồ tổ chức :

Hình 77 - Cấu trúc trang của trường Đại Học Nông Lâm

 Hệ thống Website trường Đại học Nông Lâm bao gồm:

-Hiển thị những thông tin mới nhất về trường: Giới thiệu, Ban giám hiệu, địa chỉ liên
lac, Sơ đồ trường, Bản tin nội bô, Thông báo – Tin Tức và Danh mục các WebSite
đơn vị liên kết.

-Danh mục các WebSite đơn vị liên kết bao gốm:

• WebSite các khoa (18)

• WebSite các trung tâm (9)


110
• WebSite các phòng ban(16)

• WebSite cá nhân. (Mỗi giảng viên của trường đều có thể tạo một WebSite cá
nhân)

-Mỗi website đơn vị đều có người cập nhập thông tin, quản lý diễn đàn cho chính
nó.

 Cấu trúc người dùng hệ thống.

− Admin: Người có quyền cao nhất trong hệ thông. Có thể thực hiện mọi thao
tác mà hệ thống cung cấp. Nhiệm vụ chính: Cấp phát WebSite cho các khoa,
các trung tâm, các phòng ban và WebSite cá nhân , quản lý người dùng.

− CMS Manager: Mỗi WebSite đơn vi đều có một CMS Manager. Người này
có nhiệm vụ cập nhập tin tức, quản lý diễn đàn cho WebSite đơn vị đó.

− Intructor: Đây là những người sẽ có thể tạo WebSite riêng cho họ. Ngoài ra
họ còn có thể tham gia diễn đàn mà họ là thành viên.

− Student: Đây là những người có thể tham gia diễn đàn: Thêm luồng mới, trả
lời mà họ làm thành viên.

.4.1.7 Cách tạo Website đơn vị.


Mỗi Website đơn vị của khoa-bộ môn, trung tâm tin học, phòng ban là một tổ chức
(Organizations).

Để nhanh chóng tạo ra các website đơn vị cho các khoa-bộ môn, trung tâm tin học,
phòng ban ta làm như sau:

.4.1.7.1 Bước 1.
Tạo mới một tổ chức(Organizations ) đặt tên là Template For Web.

111
Hình 78 - Cách tạo Website đơn vị

Chọn Action  Quản lý các trang  View Pages. Cấu trúc TemplateForWeb:

Hình 79 - Cấu trúc trang của Template For Web

112
Đây là cấu trúc trang cơ bản cho WebSite của khoa- bộ môn. Ở phần quản lý trang
của TemplateForWeb ta chọn Tag Import/Export. Rồi chọn Xuất . Ở đây ta sẽ thấy
một số tùy cho khi Xuất, chon các tùy chon đó nếu thấy cần , Rồi nhấn Xuất. Ta sẽ
nhận được file có đuôi mở rộng là *.lar

Hình 80 - Export một Organizations

Tạo mới một organizations đặt tên khoa Thủy sản.

Hình 81 - Tạo mới 1 tổ chức

Sau đó ta chọn Action  Quản lý các trang. Chọn tag Import/Export. Chọn “Nhập”.
Rồi sau đó chỉ đến file nhận được khi ta export Template For Web. Sau hoàn thành
xong thao tác, cấu trúc trang của Khoa Thủy Sản sẽ giống hoàn toàn như cấu trúc

113
của Template For Web. Tương tự như vậy ta sẽ làm cho tất cả các khoa-bộ môn,
phòng ban và trung tâm.

Kết quả tất cả các website đơn vị như khoa-bộ môn, phòng bàn và trung tâm đều có
mẫu template giống nhau. Sau đó Admin, hoặc CMS Manager của website đơn vị đó
có thể hiểu chỉnh lại giao diện, nội dung cho phù hợp với từng đối tượng người
dùng.

.4.1.8 Danh mục các website đơn vị.


Sau đây là hình ảnh liên kết các website đơn vị của các khoa-bộ môn, phòng ban và
trung tâm:

Hình 82 - Danh mục Website của khoa

114
Hình 83 - Danh mục Website của Phòng Ban

Hình 84 - Danh mục Website của Trung tâm

115
Chương .5 Kết quả đạt được và hướng phát triển
.5.1. Kết quả đạt được
.5.1.1 Liferay
• Xây dựng cổng thông tin cho khoa CNTT – Đại học Nông Lâm TPHCM dựa
trên cổng thông tin Liferay.

• Việt hóa Liferay.

• Tao theme mới cho Liferay dựa trên theme có sẵn.

• Tích hợp một số ứng dụng viết trên JSF framework vào Liferay dưới dạng
portlet.

.5.1.2 Sakai
• Áp dụng Sakai thử nghiệm cho việc dạy và học trực tuyến một số môn học.

• Việt hóa Sakai.

• Viết công cụ mới cho Sakai (AddSite tool).

• Hiện thực Hệ thống quản lý học của Sakai.

• Hiện thực UserDirectoryProvider để cho phép Sakai có thể đọc dữ liệu người
dùng từ CSDL bên ngoài.

.5.1.3 Single Sign On


• Nghiên cứu và triển khai thành công hai kỹ thuật Single Sign On là OpenSSO
và CAS.

• Single Sign On thành công cho Liferay, Sakai và 1 số ứng dụng web java
khác dựa trên CAS.

• Xây dựng thành công framework để áp dụng CAS cho các ứng dụng web.

.5.2. Hướng phát triển


• Phát triển cổng thông tin cho trường Đại học Nông Lâm dựa trên cổng thông
tin Liferay.

• Phát triển một số portlet riêng cho khoa/trường trong cổng thông tin.

• Áp dụng Sakai thực tế cho khoa CNTT.

116
• Phát triển và viết mới một số công cụ cho Sakai phù hợp vớ việc dạy và học ở
trường Đại học Nông Lâm.

• Đồng bộ dữ liệu người dùng của trường với các hệ thống Liferay, Sakai,
CAS.

• Xác thực OpenSSO với các CSDL người dùng tồn tại sẵn.

117
TÀI LIỆU THAM KHẢO
CAS

- Developer’s Discussion List: http://tp.its.yale.edu/mailman/listinfo/CAS-dev

- Source code: http://developer.ja-sig.org/source/

- Homepage: http://www.jasig.org/CAS

- Download: http://www.jasig.org/CAS/download

- Forum: http://www.nabble.com/CAS-Users-f15449.html

- CAS Overview: http://www.jusfortechies.com/CAS/overview.html

OPENSSO

- Home page: https://opensso.dev.java.net/

- Download : https://opensso.dev.java.net/public/use/index.html

- Forum: https://opensso.dev.java.net/servlets/ForumMessageList?forumID=1554

- OpenSSO Document: http://docs.sun.com/app/docs/coll/1767.1

- Policy Agent 3.0 Document: http://docs.sun.com/app/docs/doc/820-4803/

- OpenSSO getting started: http://wikis.sun.com/display/OpenSSO/getstarted

Khác

- Yale CAS client:

http://www.ja-sig.org/wiki/display/CASC/Yale+CAS+client+distribution

- Acegi sites Home page: http://www.acegisecurity.org/

- Download: http://www.acegisecurity.org/downloads.html

- Spring Security Home page:

http://static.springsource.org/spring-security/site/index.html

- Download: http://static.springsource.org/spring-security/site/downloads.html

- Security Filter Home page: http://securityfilter.sourceforge.net/

- Download: http://sourceforge.net/projects/securityfilter/files/
118
OpenDS

- Home page: http://www.opends.org/

- User document: https://docs.opends.org/2.0

PHỤ LỤC

A.Một số so sánh giữa Moodle và Sakai.


Moodle là giải pháp đào tạo trên mạng, được phân phối miễn phí dưới bản quyền mã
nguồn mở. Moodle được sáng lập năm 1999 bởi Martin Dougiamas.

Một tổ chức có quyền truy cập hoàn toàn mã nguồn và có thể thay đổi nếu cần thiết.

Moodle là một giải pháp học tập lý tưởng trên mạng cho:

• Các trường phổ thông (K-12).

• Cao đằng.

• Đại học.

• Các đại lý của chính phủ.

• Doanh nghiệp.

• Các tổ chức kinh doanh.

• Các bệnh viện.

• Các thư viện.

• Các đại lý tuyển dụng.

Hiện tại có 46601 trang web sử dụng Moodle trên 209 quốc gia. (Tham khảo
http://moodle.org/sites/ ).

119
So sánh một số tính năng cơ bản hỗ trợ việc dạy và học
trực tuyến.

Quản lý người dùng.

Đăng ký sử dụng hệ thống: Cả hai đều cho phép người dùng tự đăng ký.

Moodle

Hệ thống hỗ trợ sẵn việc thêm danh sách người dùng từ tệp tin dưới định dạng csv.
Sakai

Để thêm hàng loạt người dùng vào hệ thống, Sakai phải sử dụng dịch vụ bên ngoài
hoặc người phát triển phải phát triển thêm công cụ hỗ trợ gắn vào hệ thống.

Quản lí khóa học.

Tạo khóa học.

Cả hai đểu hỗ trợ người dùng tạo một trang web để dạy và học trực tuyến, trong đó
có một số công cụ cơ bản như: sổ điểm, bài giảng, bài tập, bài thi, báo cáo tình hình
học tập, diễn đàn.

Moodle

Khi tạo khóa học, ngoài việc cho phép sinh viên tự đăng ký vào khóa học trực tuyến,
hệ thống còn có thể lấy thông tin đăng ký từ nhiều nguồn bên ngoài như: External
Database, LDAP, File.

Tuy nhiên, để tương tác với các nguồn bên ngoài, thì các nguồn đó phải có cấu trúc
theo một quy tắc nào đó.

Sakai

120
Để lấy thông tin đăng ký môn học có sẵn bên ngoài Sakai, người phát triển phải hiện
thực lại hệ thống quản lý khóa học trong Sakai sao cho phù hợp với ngưồn dữ liệu
bên ngoài.

Các công cụ để dạy và học.

Cả hai đều hỗ trợ các công cụ cơ bản: Sổ điểm, bài tập, kiểm tra, diễn đàn, lịch học.

Đề cương môn học (Syllabus).

Moodle

Giảng viên giới thiệu đề cương môn học trong phần mô tả khóa học (khi tạo khóa
học) kết hợp với việc giới thiệu tài liệu môn học, bài tập, bài kiểm tra … trong
khoảng thời gian tương ứng.

Hình 85 - Hoạt động hàng tuần

Sakai

Giảng viên sử dụng công cụ Syllabus để giới thiệu nội dung của môn học, kết hợp
với công cụ Schedule để giới thiệu tài liệu môn học, thông báo các sự kiện diễn tra
phục vụ cho môn học trong khoảng thời gian tương ứng.

121
Tạo bài kiểm tra.

Moodle

Hình 86 - Moodle - Các loại câu hỏi

Đặc biệt Moodle có hỗ trợ Giảng viên có thể tạo công thức toán học dễ dàng do tích
hợp bộ soạn thảo công thức toán học LaTeX.

Ví dụ:

$$z = \sqrt{x^2 + y^2}$$ cho kết quả z= x2 + y2

$$\sum_{k=1}^n k$$ cho kết quả

Sakai

Giảng viên có thể tạo các câu hỏi với loại đúng/sai, trắc nghiệm, điền vào chỗ trống,
bảng thăm dò ý kiến, … tương tự Moodle nhưng không hỗ trợ việc tạo công thức
toán học như Moodle.

Các chuẩn bài giảng.

Cả hai đều hỗ trợ hai loại bài giảng trực tuyến phổ biến là SCORM và IMS.

Moodle

Hỗ trợ thêm chuẩn AICC.


122
Phiên bản Moodle 1.9 hiện nay chỉ hỗ trợ SCORM 1.2, phiên bản SCORM 2004
chưa được hỗ trợ. (Theo http://docs.moodle.org/en/SCORM cập nhật ngày
10/06/2009)

Sakai

Phiên bản Sakai 2.1 hỗ trợ module SCORM player trình diễn được SCORM 1.2,
nhưng không trình diễn được SCORM 2004.

Phiên bản Sakai 2.4 trở lên hỗ trợ module SCORM player trình diễn được SCORM
2004, nhưng không trình diễn được SCORM 1.2.

Tuy nhiên, hầu hết các công cụ hỗ trợ tạo gói SCORM (như Reload Editor, eXe…)
đều có thể chuyển đổi SCORM 1.2 sang SCORM 2004.

B.Hiện thực UserDirectoryProvider.


Mục đích

Sakai mặc định lưu trữ thông tin người dùng trong CSDL của chính nó (Internal
Database).

Tuy nhiên, Sakai cũng cho phép lưu trữ người dùng ở bên ngoài từ nhiều nguồn như
LDAP, Kerberos, external database, tệp tin….

Và Sakai đã hiện thực sẵn hỗ trợ việc xác thực thông qua giao thức Kerberos, LDAP
( với 2 LDAP server là OpenLDAP và JLDAP).

Nhưng do nhu cầu truy xuất người dùng có sẵn từ CSDL bên ngoài, nên chúng ta sẽ
xây dựng một Provider để hỗ trợ việc này.

Thực hiện

Tạo thư mục và các file cấu hình cần thiết.

Trong project providers cùa Sakai, tạo thêm một source package external-db và
package vn/edu/hcmuaf/sakai/user.

123
Hình 87 - Cây thư mục providers

Eclipse sẽ phát sinh thư mục external-db. Tạo pom.xml với nội dung

124
<?xml version="1.0"?>
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>providers-base</artifactId>
<groupId>org.sakaiproject</groupId>
<version>M2</version>
<relativePath>../pom.xml</relativePath>
</parent>
<name>nlu-external-provider</name>
<groupId>org.sakaiproject</groupId>
<artifactId>nlu-external-provider</artifactId>
<organization>
<name>Nong Lam University</name>
<url>http://www.hcmuaf.edu.vn</url>
</organization>
<inceptionYear>2009</inceptionYear>
<packaging>jar</packaging>
<properties>
<deploy.target/>
</properties>
<dependencies>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.0.4</version>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-authz-api</artifactId>
<version>${sakai.version}</version>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-entity-api</artifactId>
<version>${sakai.version}</version>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-user-api</artifactId>
<version>${sakai.version}</version>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-util-api</artifactId>
<version>${sakai.version}</version>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-util</artifactId>
<version>${sakai.version}</version>
</dependency>
</dependencies>
<build>
<resources/>
</build>
</project>

Trong pom.xml của project providers, thêm module external-db


<?xml version= “ 1.0“ ?>
125
<project xmlns="http://maven.apache.org/POM/4.0.0">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>base</artifactId>
<groupId>org.sakaiproject</groupId>
<version>M2</version>
<relativePath>../pom.xml</relativePath>
</parent>
<name>Sakai Providers Project</name>
<groupId>org.sakaiproject</groupId>
<artifactId>providers-base</artifactId>
<packaging>pom</packaging>
<modules>
<module>allhands</module>
<module>cm/cm-authz-provider</module>
<module>cm/cm-cm-provider</module>
<module>component</module>
<module>federating</module>
<module>imsent</module>
<module>jLDAP</module>
<module>kerberos</module>
<module>openLDAP</module>
<module>sample</module>
<module>external-db</module>
</modules>
</project>

Hiện thực interface UserDirectoryProvider.

Tạo lớp ExternalUserDirectoryProvider hiện thực UserDirectoryProvider, gồm bốn


phương thức:
public boolean authenticateUser(String eid, UserEdit edit, String password) {
//phương thức này giúp chúng ta định nghĩa nguyên tắc xác thực dựa vào mã người dùng eid
và password. Eid và password sẽ được truyền vào từ form login của Sakai.
}
public boolean authenticateWithProviderFirst(String eid) {
// TODO Auto-generated method stub
return false;
}
public boolean findUserByEmail(UserEdit edit, String email) {
//phương thức này trả về false nếu không người dùng nào có email đã cho
//trả về true, tồn tại người dùng có email đó và thông tin bổ sung sẽ được gán vào tham số
edit.
return false;
}
public boolean getUser(UserEdit edit) {
//phương thức này trả về false nếu người dùng không hợp lệ
//trả về true, nếu người dùng có trong CSDL và thông tin bổ sung về người dùng (ngoài eid
và password) sẽ được gán lại và tham số edit.
}
public void getUsers(Collection users) {
// phương thức này sẽ kiểm tra xem user trong danh sách users có tồn tại không, user nào
không tồn tại sẽ bị bỏ khỏi users
}

Deploy.
126
Chạy cmd, dẫn đến thư mục của project providers, chạy lệnh mvn clean install
sakai:deploy

Cấu hình trong tomcat.

Ở thư mục TOMCAT_HOME\components\sakai-provider-pack\WEB-INF

Xóa components-demo.xml

Sửa trong components.xml

Bỏ comment và chỉnh sửa:

<bean id="org.sakaiproject.user.api.UserDirectoryProvider"

class="org.sakaiproject.provider.user.SampleUserDirectoryProvider"

init-method="init"

destroy-method="destroy"

singleton="true">

<property name="courseStudents"><value>500</value></property>

</bean>

Thành

<bean id="org.sakaiproject.user.api.UserDirectoryProvider"

class="vn.edu.hcmuaf.sakai.user.ExternalUserDirectoryProvider"

init-method="init"

destroy-method="destroy"

singleton="true">

</bean>

Khởi động Tomcat.

Chạy server Tomcat, rồi đăng nhập thử với người dùng lưu ở CSDL bên ngoài.

127

You might also like