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.

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.

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ênchú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ưngvẫ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ảocủ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 tronggiả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 6

1.2.3 Tạo user và group trong OpenSSO 12

1.2.4 Tạo Agent Profile Trong OpenSSO 14

1.2.5 Cài đặt Policy Agent 3.0 16

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

1.3 Central Authenticate Service (CAS) 20

1.3.1 Giới thiệu 20

1.3.2 Triển Khai 29

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

1.4.1 Triển Khai 41

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

2.1 Giới thiệu Sakai project 45

2.2 Tính năng 46

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

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

2.3.2 Gradebook – Sổ điểm 48

2.3.3 Assignment – Bài tập 53

2.3.4 Tests and Quizzes – Kiểm tra 58

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

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

2.4.1 Announcement – Thông báo 63

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

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

2.5.1 Giới thiệu Sakai CMS 66

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

2.5.3 Hiện thực Sakai CMS 68

2.5.4 Demo 69

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

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

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

2.6.3 Triển khai 72

Chương 3 Giới thiệu Portal – Liferay 73

3.1 Portal là gì? 73

3.2 Giới thiệu về Liferay 75

3.2.1 Giới thiệu 75

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

3.2.3 Tạo theme mới cho Liferay 76

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

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

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

4.1.1 Giới thiệu 82

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

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

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

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

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

4.1.7 Cách tạo Website đơn vị 102

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

Chương 5 Kết quả đạt được và hướng phát triển 107

5.1 Kết quả đạt được 107

5.1.1 Liferay 107

5.1.2 Sakai 107

5.1.3 Single Sign On 107

5.2 Hướng phát triển 107

PHỤ LỤC 1

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

B Hiện thực UserDirectoryProvider 5

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 7

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 9

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

Hình 10 - User Data Store Settings 11

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

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

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

Hình 14 - Tạo Agent Profile 14

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

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

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

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

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 server26 Hình 20 - CAS – Login Flow 27

Hình 21 - CAS – Proxy Flow 28

Hình 22 - CAS – Logout Flow 29

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

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

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

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

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

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

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

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

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

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

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

Hình 34 – Sổ điểm 48

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hình 50 - Sakai Presentations 62

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

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

Hình 53 - Mô hình Simple 68

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

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

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

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

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

Hình 60 - Cấu trúc trang 88

Hình 61 - Trang chủ 89

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

Hình 63 - Trang Chương trình đào tạo 91

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

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

Hình 66 - Trang đoàn thể 93

Hình 67 - Trang thời khóa biểu 94

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

Hình 69 - Trang Nghiên cứu 95

Hình 70 - Trang Mẫu đơn 96

Hình 71 - Trang Sơ đồ trang 97

Hình 72 - Trang Diễn đàn 97

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

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

Hình 75 - Trang quản lý hình ảnh 99

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

Hình 77 - Công cụ cho giảng viên 100

Hình 79 - Cách tạo Website đơn vị 102

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

Hình 81 - Export một Organizations 104

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

Hình 83 - Danh mục Website của khoa 105

Hình 84 - Danh mục Website của Phòng Ban 105

Hình 85 - Danh mục Website của Trung tâm 106

Hình 85 - Hoạt động hàng tuần 3

Hình 86 - Moodle - Các loại câu hỏi 3

Hình 87 - Cây thư mục providers 6

TÓM TẮT

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 learning.

OpenSSO và CAS

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

Sakai Hiện thực lại hệ thống CMS và viết tool cho Sakai

đưa vào Liferay

Học Nông Lâm TPHCM, dựa trên cổng thông tin 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êntoà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ộtlầ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ọcthông qua mạng Internet Trước sự phát triển đó, nhóm chúng em mong muốn đượctì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êncứ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ácphá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ổngthô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 tintheo cơ chế Single Sign On

NỘI DUNG BÁO CÁO

1.1 Single Sign On.

1.1.2 Lợi ích

- Tránh việc nhớ nhiều thông tin đăng nhập (username & password) khi dùngnhiề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

- 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ậttrong ứ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

- JOSSO (Java Open Sigle Sign On), CoSign,…

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 SystemFedearation 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 rabả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

o Quản lý việc truy xuất vào tài nguyên của người dùng thông qua policy agent Những chính sách bảo mật tài nguyên sẽ được thiết lặp trong policyagent và người dùng vào được tài nguyên hay không là căn cứ vào chính sách này

Ví dụ: role: admin được phép truy xuất vào tài nguyên /app#1/*

o Policy agent chặn các request truy xuất vào tài nguyên được bảo vệ vàtruyền đến OpenSSO để xác thực request này.

- Federation Management

o Chức năng này cho phép single sign on nhiều tổ chức, hay nhiều domain

- 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 Khi một người gởi Http request để truy cập tài nguyên đượcbảo vệ, policy agent chặn request này và kiểm tra Nếu OpenSSO token được tìmthấ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ấpphé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

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 tokenchư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ậpUsername / Password để xác thực

- 4 Opensso activate login session (tức là tạo ra session cho người dùng và kíchhoạ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 tinauthorization (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 sessiontrên URL

Hình 5 - Sơ đồ hoạt động chi tiết với policy1.2.2 Triển Khai.

1.2.2.1 Triển khai OpenSSO trên Server.

Trên GlassFish v2

Yêu cầu

này sử dụng domain mặc định domain1 cho opensso, có thể tạo domainkhác)

/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.

c:/opensso/deployable-war dùng để triển khai

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

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

tài khoản admin/adminadmin

đế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ầncấ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 fileopensso.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ặ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ụngcổ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

(VD: password là “adminadmin”)

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

“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

cho Amadmin user Nhấn 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ìnhcủa OpenSSO Enterprise Nhấn Next để tiếp tục

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

trên Sun Java System Directory Server

o SSL Enable: sử dụng sử dụng giao thức LDAPs để kết nối đếnDirectory 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

o OpenSSO User Data Store: Lưu trữ dữ liệu người dùng trongOpenSSO 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 datastore như: Sun Java System Directory Server, Microsoft ActiveDirectory hoặc IDM 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ảoInstall Sun Java System Directory Server and Creating Instance forSun OpenSSO Enterprise User Data

Hình 10 - User Data Store Settings

o User Store Detail

OpenSSO Schema Loaded

 Generic LDAP: Directory Server khộng co OpenSSOSchema loaded

Nhấn Next để tiếp tục

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ềnAdmin 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 OpenSSO1.2.3.1 Tạo user.

user Chọn OK hoàn tất tạo user (đánh dấu chọn vào active để kích hoạt user)

xem chi tiết và những tab con:

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ôngtin

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à nhấn OK để hoàn tất

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êmuser vào group Nhấn Save để lưu lại thông tin

Hình 13 - Thêm user vào group trong OpenSSO1.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.

Nhấn RealName  Agent  J2EE New

Hình 14 - Tạo Agent Profile

Đ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 webserver 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 filetext để 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 tinagent bằng giao diện) Nếu chọn Local, bạn không thể quản lý agentbằ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ìnhnày Ví dụ: Ta sẽ cài đặt Agent trong domain đã tạo ở trên :

Ứng dụng agentapp là một ứng dụng web, sẽ triển khai lên domain nàysau 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.

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

NameAgent J2EE tab Agent Name

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

“Coressponding Map Value”

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

giá trị vào thuộc tính Login Form URI (giá trị này được cấu hình trongweb.xml của ứng dụng với thẻ “Form-Login-Page” )

Hình 15 - Cấu hình Login Form URI trong OpenSSO1.2.5 Cài đặt Policy Agent 3.0

Agent cài đặt chung server với những ứng dụng mà nó bảo vệ

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

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)

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

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

Cài đặt

C:/myagent/j2ee-agents/ appserver_v9_agent/bin và gõ lệnh agentadmin –install để bắt đầu.

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

o Application server config directory path: Đường dẫn đến thư mụcconfig 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)

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

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 khicài đặt agent thành công, đây là agent đã được cài đặt chứa thông cấuhì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 webserver (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

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 webcontainer nào Vì mỗi web container sẽ có yêu cầu cấu hình khác nhau chomỗi ứng dụng về bảo mật

dùng

o Ứng dụng đã tồn tại các cấu hình về security, đã khai báo trong fileweb.xml, vì thế việc cấu hình làm sao để Agent hiểu ứng dụng đã tồntạ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áchbảo mật cho ứng dụng sẽ làm toàn bộ trên Agent

1.2.6.2 Yêu Cầu.

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

 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ácthực là FORM.

- 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, X509Certificate, để 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ínhnă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ìnhduyệ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.

- Đượ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

- 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.

- 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ácnhau 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

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

- /serviceValidate sẽ trả về một xml-formatted response Khi thành công, responsechứa username và proxy-granting ticket Khi thất bại, response chứa một mã lỗivới thông điệp thất bại tương ứng Sau đây là một số mã lỗi được trả về responsenế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 ticketkhô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 proxyticket 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 Serviceidentifier 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ệ

không 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

sửa

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ẽ đượckiể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ộtHTTP Cookie của CAS Cookie này duy trì trạng thái đăng nhập cho client Khiclient 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-“

- Proxy Ticket là một chuỗi ký tự ngẫu nhiên mà một service sử dụng như thôngtin đă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 khichú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

proxy callback url được chỉ định như một request parameter Proxy callback urlphả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útTGTIOU 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 quagiao thức HTTPS

o Nếu TGC này là hợp lệ, CAS server trả về một Service Ticket cho trìnhduyệ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ó choCAS 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 CASserver

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 Vì chưa nhận đượcTGC 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 đăngnhập để CAS xác thực Thông tin được truyền đi thông qua giao thứcHTTPS

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

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 server1.3.1.6 CAS Architecture.

Login Flow.

Hình 20 - CAS – Login Flow

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ạnthì CAS sẽ buộc người dùng nhập thông tin đăng nhập vào khung đăng nhập

- Người dùng nhập thông tin đăng nhập và chọn Submit, CAS sẽ lấy danh sáchAuthenticationHanders từ deployerConfigContext.xml và kiểm tra xem nó hỗtrợ AuthenticationHander nào Nó sẽ đưa thông tin đăng nhập choAuthenticationHander mà nó hỗ trợ và kiểm tra thông tin đăng nhập củangười dùng Nếu người dùng xác thực không hợp lệ sẽ được chuyển đếnkhung đă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.

Registry CAS kiểm tra có hay không service parameter thông qua /loginURL

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 traservice và service ticket /serviceValidate sẽ được gọi bởi filter của client

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

Ticket param name: ticket

Service Ticket value: ST-1856339-aA5Yuvrxzpv8Tau1cYQ7

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

Proxy Flow

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 urlhay 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 đăngxuất thành công

Hạn chế

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ảicấ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

//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

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?

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ấ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

Ch này ph i đi ỗ này phải đi ải đi ền full domain

<! Define a SSL HTTP/1.1 Connector on port 8443 >

<Connector port="8443" maxHttpHeaderSize="8192" SSLEnabled=”true”

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

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

sau:

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

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

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

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

<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" />

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