Luận văn công nghệ thông tin Tìm hiểu và triển khai hệ thống đăng nhập 1 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 (Elearning).

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.. Thông tin này sẽ được sử dụng đế cấu hì

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

DANH SÁCH CHỮ VIẾT TẮT

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

API Application Programming Interface

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 3

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 7

1.2.3 Tạo user và group trong OpenSSO 14

1.2.4 Tạo Agent Profile Trong OpenSSO 16

1.2.5 Cài Đặt Policy Agent 3.0 19

1.2.6 Bảo vệ ứng dụng Java EE Application với OpenSSO Policy Agents 22

1.3 Central Authenticate Service (CAS) 23

1.3.1 Giới thiệu 23

1.3.2 Triển Khai 34

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

1.4.1 Triển Khai 48

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

2.1 Giới thiệu Sakai project 53

2.2 Tính năng 54

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

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

2.3.2 Gradebook – Sổ điểm 57

2.3.3 Assignment – Bài tập 62

2.3.4 Tests and Quizzes – Kiểm tra 70

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

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

2.4.1 Announcement – Thông báo 74

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

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

2.5.1 Giới thiệu Sakai CMS 78

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

2.5.3 Hiện thực Sakai CMS 81

2.5.4 Demo 81

2.6 Triển khai một ứng dụng viết thêm cho Sakai 81

2.6.1 Cài đặt một ứng dụng từ bên ngoài vào Sakai 81

2.6.2 Viết một webapp làm việc như một tool trên Framework của Sakai 83

2.6.3 Triển khai 85

Chương 3 Giới thiệu Portal - Liferay 86

3.1 Portal là gì? 86

3.2 Giới thiệu về Liferay 93

3.2.1 Giới thiệu 93

3.2.2 Hướng dẫn cài đặt 94

3.2.3 Thiết lập Cơ sở dữ liệu cho Liferay 96

3.2.4 Hướng dẫn Việt-hóa Liferay 100

3.2.5 Tạo theme mới cho Liferay 102

3.2.6 Tạo Porlet 103

3.2.7 Quản lý nội dung với CMS: 110

Chương 4 Xây dựng FIT Portal dựa trên Liferay Portal 113

4.1.1 Giới thiệu 113

4.1.2 Các vai trò (role), hệ thống người dùng sẵn có trong Liferay 113

4.1.3 Các role, hệ thống người dùng xây dựng thêm trong FIT portal 114

4.1.4 Đối tượng người dùng trong hệ thống FIT portal 115

4.1.5 Quy trình tạo mẫu tin của hệ thống FIT portal 118

4.1.6 Cài đặt các trang trong hệ thống 119

4.1.7 Cách tạo Website đơn vi: 139

4.1.8 Danh mục các website đơn vị 143

4.2 Hướng dẫn sử dụng 146

4.2.1 Cách tạo User, Role, User group 146

4.2.2 Phân quyền truy xuất các portlet 148

4.2.3 Phân quyền cho hiển thị, chỉnh sửa trang Web : 150

4.2.4 Sử dụng ứng dụng có sẵn của Liferay 151

4.2.5 Thêm ứng dụng mới vào Liferay 151

PHỤ LỤC 153

A Một số so sánh giữa Moodle và Sakai 153

B Hiện thực UserDirectoryProvider 160

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 5

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 7

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

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

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

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

Hình 10 - User Data Store Settings 13

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

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

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

Hình 14 - Tạo Agent Profile 17

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

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

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

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

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 30

Hình 20 - CAS – Login Flow 31

Hình 21 - CAS – Proxy Flow 33

Hình 22 - CAS – Logout Flow 33

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

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

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

Hình 26 - Cấu hình Liferay - LDAP 44

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

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

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

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

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

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

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

Hình 34 - Tạo đề cương 56

Hình 35 – Sổ điểm 57

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

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

Hình 38 - Tạo bài tập - Thêm đính kèm 65

Hình 39 - Đính kèm file từ resource cho bài tập 66

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

Hình 41 – Chấm điểm 68

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

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

Hình 44 - Soạn nội dung câu hỏi 72

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

Hình 46 - Sử dụng Công cụ Presentations 74

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

Hình 54 - Mô hình miền Sakai CMS 79

Hình 55 - Mô hình Simple 80

Hình 56 - Mô hình Large Lecture 80

Hình 60 - Build Liferay 96

Hình 61 - Sơ đồ khái quát về hệ thống người dùng của WebSite 117

Hình 62 - Quy trình tạo mẫu tin của hệ thống FIT portal 119

Hình 63 - Cấu trúc trang 120

Hình 64 - Trang chủ 122

Hình 65 - Trang Sơ đồ tỗ chức khoa Công Nghệ Thông Tin 123

Hình 66 - Trang Chương trình đào tạo 124

Hình 67 - Cấu trúc trang cho Sinh viên 124

Hình 68 - Trang hiển thị danh sách sinh viên đại học 125

Hình 69 - Trang đoàn thể 126

Hình 70 - Trang thời khóa biểu 127

Hình 71 - Trang tìm nhanh Thời khóa biểu 128

Hình 72 - Trang Nghiên cứu 129

Hình 73 - Trang Mẫu đơn 130

Hình 74 - Trang Sơ đồ trang 131

Hình 75 - Trang Diễn đàn 132

Hình 76 - Trang thêm thời khóa biểu 133

Hình 77 - Trang quản lý tài liệu 134

Hình 78 - Trang quản lý hình ảnh 134

Hình 79 - Cấu trúc trang của các Website cá nhân của giảng viên 135

Hình 80 - Công cụ cho giảng viên 136

Hình 81 - Trang chủ Trường Đại Học Nông Lâm 137

Hình 82 - Cấu trúc trang của trường Đại Học Nông Lâm 138

Hình 83 - Cách tạo Website đơn vi 140

Hình 84 - Cấu trúc trang của Template For Web 141

Hình 85 - Export một Organizations 142

Hình 86 - Tạo mới 1 tổ chức 143

Hình 87 - Danh mục Website của khoa 144

Hình 88 - Danh mục Website của Phòng Ban 145

Hình 89 - Danh mục Website của Trung tâm 146

Hình 90 - Phân quyền truy xuất các portlet 149

Hình 91 - Phân quyền truy xuất các portlet (t.t) 150

Hình 92 - Phân quyền cho hiển thị, chỉnh sửa trang Web 150

Hình 93 - World of Moodle 154

Hình 94 - Upload users 155

Hình 95 - Enrollment 156

Hình 96 - Enrollment - External DB 156

Hình 97 - Enrollment - LDAP 157

Hình 98 - Hoạt động hàng tuần 158

Hình 99 - Moodle - Các loại câu hỏi 159

Hình 100 - Cây thư mục providers 161

TÓM TẮT

 Tên đề tài: Tìm hiểu và triển khai hệ thống đăng nhập 1 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).

OpenSSO và CAS

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

trực tuyến Sakai

đưa vào Liferay

Nông Lâm bằng Liferay

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ì nhóm em nghiên cứu được 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 Từ đó 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

Đánh giá các vấn đề đã đạt: Dù không hoàn tất các yêu cầu đề ra, nhưng những vấn đề

đã đạt được thì hoàn toàn nằm trong khả năng hiểu biết của nhóm Chương trình ứng dụng được trên thực tế và đủ khả năng quản lí

Vấn đề chưa đạt: Triển khai Single Sign On cho hai hệ thống lớn là Liferay và Sakai

Chưa ứng dụng được Sakai cho việc học trực tuyến tại trường

Hướng phát triển: Kết hợp cổng thông tin khoa và hệ thống học trực tuyến Sakai,

dùng cơ chế Single Sign On cho hai hệ thống này Xây dựng module riêng cho khoa trên hệ thống Sakai

NỘI DUNG BÁO CÁO

1.1 Single Sign On.

1.1.2 Lợi ích

- Giảm đi sự mệt mỏi không cần thiết khi phải nhớ nhiều thông tin đăng nhập

(username & password) khi dùng nhiều dịch vụ

- Giảm thời gian tái lập lại mật khẩu cho cùng 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

- 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

- OpenSSO 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: 7/2008 bản Express được công bố, cập nhật 3 tháng một lần

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

OpenSSO Enterprise 8.0 được công bố Từ 12-15 tháng sẽ đưa ra 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

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 vào tài nguyên Khi một người gởi Http request để vào 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 sẽ giải thích sự tương tác giữa các tổ chức (policy agent, browser,

protected application)

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

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

- 1 Đầu tiên từ trình duyệt , người dùng kết nối đến ứng dụng web

- 2 Tiếp theo, Policy Agent sẽ kiểm tra token có tồn tại trong URL hay không? Nếu token không 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 User nhập

- 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

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

tôi sử dụng domain mặt định là domain1 cho opensso, bạn 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>

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

o Save và hoàn tất

dụ: c:/opensso) File opensso.war nằm trong thư mục c:/opensso/deployable-war

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

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

domain1”:

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

khoản admin/adminadmin

đến file opensso.war trong thư mục c:/opensso/deployable-war/

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

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

1.2.2.2 Cấu hình mặt đị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

nhập vào Opensso với user/password: amadmin/adminadmin

 Chú ý: sau khi cấu hình mặt đị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

Amadmin user

Click Next để tiếp tục

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:

o Configuration Directory: Là vị trí thư mục để lưu thông tin cấu hình của OpenSSO Enterprise

Click Next to continue

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

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

o Configration Data Store:

configuration_directory/opends trên local server

Sun Java System Directory Server

o SSL Enable: Kiểm tra xem có sử dụng LDAPs để kết nối đến Directory Server hay không

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

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ỏ Những sản phẩm triển khai không yêu cầu

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ặcIDM Tivoli Directory Server

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 InstallSun Java System Directory Server and Creating Instance for Sun

OpenSSO Enterprise User Data

Hình 10 - User Data Store Settings

o User Store Detail

OpenSSO Schema Loaded

Schema loaded

Click next to continue

 Site configuration :

Check No Click next to continue

Click next to continue

1.2.3 Tạo user và group trong OpenSSO.

Muốn cấu hình trong opensso, trước tiên phải login vào opensso amadmin ChọnAccess ControlReal NameSubject (tab 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.

chọn ok hoàn tất tạo user (chú ý check vào active để kích hoạt user)

 Sau khi ok, sẽ quay lại tab user hiển thị tất cả user hiện có Sau đó click vào user vừa tạo để xem chi tiết và những tab con:

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

o General: hiển thi 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.

điền ID của Group và click ok để hoàn tất

o General: hiển thi thông tin của group (không cho phép chỉnh sửa) Sau khi tạo group, thông tin group cấu trúc phân (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à click Add để thêm user vào group Click save để lưu lại thông tin

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

1.2.4.2 Tạo Agent Profile

RealName  Agent  J2EE tabclick New button

Hình 14 - Tạo Agent Profile

Điền đầy đủ thong 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à đặ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à chỉ của Agent mà dự sẽ cài đặt sau phần cấu hình này Ví

dụ : tôi dự cài đặt Agent trong domain đã tạo ở trên :

Địa chỉ agent là : http://nonglam.cntt.com:8888/agentappỨng dụng agentapp là môt web app, sẽ triển khai lên domain này sau khi cài đăt agent.

o Click button create để tạo agent

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

o Để cấu hình agent thì phải vào agent profile và opensso đã tạo để cấu hình 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 song, bắt buộc phải chạy lại container (web server chứa agent) Nếu

“Hot-swap:yest” thì không cần chạy lại container

NameAgent J2EE tab Agent Name

o Click và link General và tìm đến thuộc tính Agent Filter Mode: xóa hết

“Coressponding Map Value”

o Chú ý chọn Save (ở góc phải trên của màn hình) để lưu kết quả

o Đến thuộc tính Agent Debug Level: và check vào “message” và chọn save

để lưu

tri vào thuôc tính Login Form URI (giá tri này được cấu hình trong file 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

cài đặt ở một server khác với Opensso và chung 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

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ị

phải giống với password đã lưu trong Agen Profile (ví dụ: adminadmin)

có rối thì 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.

Chú ý: Chạy server chứa Opensso (ví dụ: chạy domain1) trước khi cài đặt Agent

Cài đặt

appserver_v9_agent/bin và gõ lệnh agentadmin install để bắt đầu cài đặt

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

1.2.5.2 Sử dụng Policy Agent 3.0

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

 Sau cài đặt agent, sẽ có kiến trúc như sau:

Hình 17 - Kiến trúc thư mục 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à file 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

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

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

khai báo Agent Filter của J2EE Agent trong web.xml của ứng dụng Copy và paste đoạn khai báo sau vào web.xml của ứng dụng

 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à

1.2.6.3 Cài đặt Policy Agent 3.0 trên web containter

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ẽ bi hủy khi user đăng xuất vớ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, 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 click chọn “Remember me” Check Box trên login form, thì thông tin đăng nhập sẽ được ghi nhớ với thời gian được cấu hình (mặt định là 3 tháng) và khi người dùng mở mới trình duyệt thì cas sẽ chuyển đế service url tương ứng mà không cần hiển thị login form

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

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

- Là một Web single sign on

- Rất dễ sử dụng

- Cũng được tạo ra bởi by Yale University

- Giới thiệu thêm tính năng mới là proxy authentication

- 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 đã logout

Tham số “url” có thể được chỉ định đến /logout và nếu được chỉ định, “url”

sẽ được hiển thị trong logout page cùng với thông báo đăng xuất Sau đó, người dùng click vào link “url” trong logout page, nó sẽ chuyển đến “url” được chỉ định Có thể chỉnh sửa “casLogoutView.jsp” trong thư mục \cas-server-webapp\src\main\webapp\WEB-INF\view\jsp\default\ui

 Ticket (required) – service ticket được sinh ra bởi /login

- /serviceValidate sẽ trả về một xm-formatted response Khi thành công, response chứa đựng 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

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

 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

sử dụng proxy authentication

XML-fragment và sinh ra proxy-granting ticket khi được yêu cầu

kiểm tra tính hợp của proxy ticket

/samlValidate

sách Registered Services

- 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, 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 thể single sign on

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

Ví dụ: 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 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ẽ bi hủy khi đóngtrì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 để tury 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)

- Proxy trong CAS, proxy là một service muốn truy xuất những service khác thay mặtcho một user riêng biệt Proxy Ticket (PT) được sinh ra từ CAS nhờ vào một servicethể 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 mà nó kết nối

- Proxy Ticket là một chuỗi ký tự ngẫu nhiên cái 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ầumộ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, cách chúng ta xác thực service được yêu cầu để gởi PGT, PGTIOU đển 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ó Khải năng để nhận gọi ngược lại xác thực 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 login form 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

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

o 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 Login Form để 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 sau đó 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

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

Hình 20 - CAS – Login Flow

/login Khi user nhập địa chỉ http://server/cas/login từ browser, 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ẽ