ISSN, ISI, SCI

MỘT VÀI THÔNG TIN

VỀ MÃ SỐ CHUẨN QUỐC TẾ CHO TẠP CHÍ VÀ SÁCH, VỀ SỰ PHÂN LOẠI TẠP CHÍ KHOA HỌC VÀ CÁCH TRÌNH BÀY MỘT BÀI BÁO TRONG TẠP CHÍ KHOA HỌC

Trần Văn Nhung

Để có thêm thông tin cho các ứng viên chức danh giáo sư (GS), phó giáo sư (PGS) và Hội đồng Chức danh giáo sư các cấp (HĐCDGS các cấp), chúng tôi đã tham khảo một số tài liệu trong nước và quốc tế về sự phân loại tạp chí khoa học và hệ thống hóa lại trong bài viết này. HĐCDGS các cấp đã nhận được nhiều tạp chí khoa học của Việt Nam và thế giới, nhưng vẫn còn không ít tạp chí trong nước cần phải góp ý thêm về cách trình bày một bài báo khoa học ở trong đó.

1.  Mã số ISSN cho tạp chí và mã số ISBN cho sách

ISSN (International Standard Serial Number) là mã số chuẩn quốc tế cho xuất bản phẩm nhiều kỳ (XBPNK), một mã được công nhận trên phạm vi toàn thế giới nhằm xác định nhan đề của các XBPNK. Khi đã có chỉ số ISSN, thì tạp chí sẽ được quốc tế thừa nhận chính thức và giới thiệu trên quy mô toàn cầu, hay nói nôm na là đã có "thẻ căn cước" để đi lại trong "làng" thông tin toàn cầu. Nhưng ISSN không liên quan đến việc bảo vệ quyền sở hữu, bản quyền hoặc bảo vệ nhan đề của XBPNK với các nhà xuất bản khác. Khác với sự xét chọn và phân loại theo chất lượng tạp chí khoa học của Viện Thông tin Khoa học (Institute for Scientific Information, ISI, Hoa Kỳ) hoặc Scopus của Nhà xuất bản Elsevier (Hà Lan), chỉ số ISSN của một tạp chí không liên quan đến chất lượng khoa học của các bài báo được đăng ở trong đó.

Danh sách ISSN này bao hàm và rộng hơn rất nhiều so với danh sách ISI và Scopus. Hiện nay, danh sách ISI bao gồm khoảng 10.000 tạp chí. Cho đến tháng 5 năm 2012, Scopus bao gồm 18.500 tạp chí về khoa học tự nhiên, công nghệ, kỹ thuật, y dược và khoa học xã hội của hơn 5.000 nhà xuất bản (15% của Elsevier và 85% của các nhà xuất bản quốc tế khác). Danh sách ISSN bao gồm khoảng 1,3 triệu tên XBPNK (xem mô tả ở hình dưới). Thế nhưng ở Việt Nam vẫn còn một số tạp chí chưa đăng ký để có chỉ số ISSN. Từ năm 2012, chỉ những bài báo khoa học được đăng ở các tạp chí có chỉ số ISSN mới được Hội đồng Chức danh giáo sư các cấp xem xét, tính điểm.

Văn phòng Hội đồng Chức danh giáo sư nhà nước (HĐCDGSNN) xin kiến nghị các ban biên tập tạp chí khoa học trong cả nước, sau khi tạp chí đã được Cục Xuất bản, Bộ Thông tin và Truyền thông, cấp Giấy phép xuất bản (xem như là "giấy khai sinh"), cần phải làm tiếp thủ tục đăng ký (miễn phí) mã số chuẩn quốc tế ISSN (để làm "thẻ căn cước") tại: Trung tâm ISSN Việt Nam, Cục Thông tin Khoa học và Công nghệ Quốc gia, Bộ Khoa học và Công nghệ, Số 24, Lý Thường Kiệt, Q. Hoàn Kiếm, Hà Nội, Phòng 310 (tầng 3), ĐT: 04-39349116, Fax: 04-39349127, E-mail: Tranhanh@vista.gov.vn, website: vista.vn.

Thêm vào đó, theo chúng tôi biết thì mới có rất ít sách đã được xuất bản tại Việt Nam có mã số chuẩn quốc tế ISBN (International Standard Book Number). Đây là mã số chuẩn quốc tế để xác định một quyển sách. Trên thế giới, khái niệm và việc đăng ký mã số ISBN cho sách được bắt đầu từ những năm 1966-1970 và đã trở thành thông lệ, còn ở ta mới từ năm 2007. Đây là việc làm tuy nhỏ nhưng lại cần thiết để chuẩn hoá công việc xuất bản và hội nhập quốc tế. Văn phòng HĐCDGSNN sẽ kiến nghị HĐCDGS các cấp, trong tương lai gần, chỉ xem xét tính điểm những cuốn sách khoa học đã được xuất bản nhưng có mã số ISBN. Việc đăng ký mã số chuẩn quốc tế ISBN được thực hiện tại: Cục Xuất bản, Bộ Thông tin và Truyền thông, Số 10, Đường Thành, Hà Nội, ĐT: 04-39233152 và 04-39233153.

2.     Phân loại ISI

Viện Thông tin khoa học (Institute for Scientific Information, ISI, Hoa Kỳ) đã xét chọn chất lượng của các tạp chí trên thế giới một cách khắt khe và kỹ lưỡng để đưa vào cơ sở dữ liệu của họ. Mặc dù vẫn còn có những ý kiến chưa thống nhất, nhưng ISI vẫn là một trong rất ít cách phân loại được thừa nhận và sử dụng rộng rãi khi bàn luận về chất lượng khoa học của các công trình nghiên cứu. Liên hợp quốc, các Chính phủ và các Tổ chức quốc tế thường sử dụng thống kê của ISI trong quản lý và hoạch định các chính sách khoa học, kỹ thuật. Các thống kê và đánh giá về khoa học, công nghệ và kỹ thuật nếu không theo ISI thì bị lệch so với thống kê quốc tế.

ISI lúc đầu (năm 1960) chỉ bao gồm tập hợp SCI (Science Citation Index) với khoảng khoảng 4.000 tạp chí khoa học tự nhiên, kỹ thuật, công nghệ có chất lượng cao và truyền thống lâu đời nhất trên thế giới (http://science.thomsonreuters.com/cgi-bin/jrnlst/jlsubcatg.cgi?PC=K). Về sau SCI mở rộng thành tập hợp SCIE (Science Citation Index Expanded) với khoảng 7.000 tạp chí khoa học tự nhiên, kỹ thuật, công nghệ xuất bản từ năm 1900 đến nay (http://science.thomsonreuters.com/cgi-bin/jrnlst/jlsubcatg.cgi?PC=D). Hiện nay, ISI còn bao gồm tập hợp SSCI (Social Science Citation Index) với hơn 2.000 tập chí xuất bản từ năm 1956 đến nay và A&HCI (Arts & Humanities Citation Index) với hơn 1.200 tập chí xuất bản từ năm 1975 đến nay. Như vậy, ISI là tập hợp bao hàm cả SCI, SCIE, SSCI và A&HCI với tổng cộng khoảng 10.000 tạp chí khoa học có chất lượng cao, trong tổng số hàng trăm nghìn tạp chí "thượng vàng hạ cám" trên thế giới.

Chất lượng của các tạp chí ISI chủ yếu được đánh giá dựa trên qui trình kiểm duyệt để đăng bài và các thống kê về chỉ số được trích dẫn của các bài báo đăng trên tạp chí đó thông qua chỉ số ảnh hưởng (Impact Factor, IF). Các chỉ số khoa học từ nguồn ISI đã được Tổ chức xếp hạng đại học của Đại học Giao thông Thượng Hải (Trung quốc) sử dụng để đánh giá số lượng, chất lượng nghiên cứu khoa học và xếp hạng các trường đại học trên thế giới. Khi không có công bố các kết quả nghiên cứu trên các tạp chí ISI thì các trường đại học, các cơ sở nghiên cứu khoa học sẽ không bao giờ lọt được vào bảng xếp hạng quốc tế nào.

Để dễ hình dung, chúng tôi tạm phác hoạ sơ đồ mô tả sự phân loại tạp chí khoa học theo ISI và chỉ số ISSN đối với tạp chí, ISBN đối với sách như sau:

3.  Phân loại Scopus

Như đã nói ở trên, hiện nay, bên cạnh phân loại ISI, nhiều tổ chức xếp hạng thế giới, ví dụ như Tổ chức xếp hạng các cơ sở nghiên cứu khoa học SCIMAGO (http://scimagojr.com) hoặc Tổ chức xếp hạng đại học (QS World University Rankings, http://www.topuniversities.com), ..., còn sử dụng cơ sở dữ liệu từ nguồn Scopus (được xây dựng từ tháng 11 năm 2004) của Elsevier (Hà Lan). Để được liệt kê vào danh sách Scopus, các tạp chí cũng được lựa chọn nghiêm ngặt. Số lượng tạp chí nằm trong Scopus gần gấp đôi số lượng nẳm trong ISI, nhưng không bao gồm tất cả mà chỉ chứa khoảng 70% số lượng tạp chí của ISI. Tuy nhiên, nguồn Scopus chỉ bao gồm các bài báo xuất bản từ năm 1995 trở lại đây. Cách đánh giá chất lượng các tạp chí của Scopus cũng dựa vào chỉ số ảnh hưởng IF, nhưng trang web của Scopus (http://www.scopus.com) rất tiện ích khi sử dụng cho nhiều mục đích khác nhau, từ tra cứu tài liệu đến đánh giá tình hình nghiên cứu khoa học của các cá nhân và các cơ sở đào tạo, nghiên cứu, ... Các số liệu của Scopus đã được SCIMAGO sử dụng để đánh giá, xếp hạng các tạp chí khoa học và các cơ sở khoa học. Theo số liệu đó, trong số hơn 2.800 cơ sở nghiên cứu mạnh ở trên thế giới, Việt Nam chúng ta đã có tên 3 đơn vị: Viện KH-CN Việt Nam, ĐHQG TPHCM và ĐHQG HN. Đặc biệt, trang web SCIMAGO (http://scimagojr.com) mở miễn phí, trong đó các tạp chí được xếp hạng chung và xếp hạng theo từng lĩnh vực và ngành hẹp, rất thuận tiện để Hội đồng chức danh giáo sư các cấp tra cứu, đánh giá chất lượng của các tạp chí khoa học quốc tế và bài báo khoa học liên quan.

Cho đến nay, Việt Nam chưa có tạp chí khoa học nào được lọt vào danh sách ISI. Bộ KH-CN, Viện KH-CN Việt Nam và các cơ quan liên quan đã và đang cố gắng giới thiệu một số tạp chí khoa học của ta ra quốc tế để chúng ta có thể có được những tạp chí khoa học đầu tiên đạt chuẩn quốc tế ISI. Rất mừng là, vừa qua tạp chí toán học Acta Mathematica Vietnamica của Viện Toán học (Viện KH-CN Việt Nam) lần đầu tiên được lọt vào danh sách Scopus. Các quốc gia trong cộng đồng ASEAN như Malaysia đã có 48 tạp chí và Thái Lan đã có 21 tạp chí được công nhận để xếp vào hệ thống Scopus.

Chúng ta có thể tham khảo cách đánh giá các công bố quốc tế khi tài trợ cho các đề tài nghiên cứu cơ bản của Quỹ Phát triển Khoa học và Công nghê Quốc gia (NAFOSTED, website: http://nafosted.gov.vn). Cần phải nhấn mạnh thêm rằng: Đối với nhiều nước trên thế giới, trong đó có Việt Nam, công bố quốc tế không chỉ là một đòi hỏi quan trọng đối với các nhà khoa học trong lĩnh vực khoa học tự nhiên, kỹ thuật và công nghệ, mà ngay cả đối với các lĩnh vực khoa học xã hội, nhân văn,... Gần đây, khi Trung Quốc tăng cường lấn chiếm trên Biển Đông, thì chúng ta càng thấy rõ tầm quan trọng to lớn của những tiếng nói và tài liệu có căn cứ khoa học trên các diễn đàn quốc tế của các nhà khoa học Việt Nam trong các lĩnh vực như khảo cổ, lịch sử, địa lý, biển đảo, luật quốc tế, ngoại giao,... để bảo vệ chủ quyền lãnh thổ của Tổ quốc.

4.  Chỉ số H và IF

Khi xếp hạng (tương đối chính xác) các tạp chí khoa học trên thế giới người ta thường dựa vào các chỉ số “đo” chất lượng khoa học của tạp chí, ví dụ chỉ số ảnh hưởng IF (Impact Factor) và chỉ số H (H-index). “Rất khó đánh giá chất lượng các công trình nghiên cứu khoa học, vì cộng đồng khoa học vẫn chưa nhất trí một chuẩn mực thống nhất cho tất cả các lĩnh vực nghiên cứu”. Tuy nhiên, hai chỉ số (có quan hệ với nhau) thường được sử dụng để ước định chất lượng của một công trình nghiên cứu khoa học là chỉ số ảnh hưởng và số lần trích dẫn (citation index). Theo định nghĩa được công nhận, hệ số ảnh hưởng IF là số lần trích dẫn hay tham khảo trung bình các bài báo mà tạp chí đã công bố hai năm trước. Do đó, những công trình nghiên cứu được công bố trên các tạp chí có hệ số ảnh hưởng cao, ví dụ như Science, Nature, ..., thường có chất lượng khoa học rất cao. Tuy nhiên, hệ số ảnh hưởng của tạp chí cũng còn phụ thuộc vào các ngành khoa học khác nhau.

Năm 2005, nhà vật lý người Mỹ Jorge Hirsch của Đại học California ở San Diego đã đưa thêm chỉ số H (H-index) để đánh giá các kết quả khoa học và làm cơ sở so sánh đóng góp khoa học của các nhà khoa học khác nhau (trong cùng lĩnh vực). Theo Jorge Hirsch thì một nhà khoa học có chỉ số H nếu trong số N công trình của ông ta có H công trình khoa học (H < N) có số lần trích dẫn của mỗi bài đạt được từ H trở lên. Như vậy, chỉ số H chứa đựng được cả hai thông tin: số lượng (số các bài báo được công bố) và chất lượng, tầm ảnh hưởng (số lần được các nhà khoa học khác trích dẫn) của hoạt động khoa học.

Jorge Hirsch cũng đã xem xét chỉ số H cho một số nhà khoa học và đưa ra nhận xét rằng, trong lĩnh vực vật lý lý thuyết, các nhà khoa học Mỹ thành công (successful) sẽ có chỉ số H = 20 sau 20 năm; một nhà khoa học nổi tiếng (outstanding) sẽ có chỉ số H = 40 sau 20 năm; thiên tài khoa học (truly unique individual) sẽ có chỉ số H = 60 sau 20 năm. Jorge Hirsch cũng đã đề nghị rằng ở Mỹ một nhà khoa học có thể bổ nhiệm phó giáo sư (associate professor) nếu có chỉ số H khoảng 12 và giáo sư (full professor) nếu H vào khoảng 18. Các nhà khoa học được giải thưởng Nobel thường có chỉ số H trong khoảng từ 35 đến 100. Chỉ số H cao nhất của một số lĩnh vực khác như hoá - lý: 100, sinh học: 160, khoa học máy tính: 70, trong khi đó lĩnh vực kinh tế học có chỉ số H vào khoảng 40.

Thiết nghĩ, khi đánh giá các ứng viên để trao giải thưởng khoa học hoặc để công nhận đạt tiêu chuẩn và bổ nhiệm chức danh giáo sư, phó giáo sư, nếu chúng ta tham khảo thêm chỉ số H của ứng viên đó thì sẽ có thêm thông tin về mức độ ảnh hưởng của ứng viên đó trong cộng đồng khoa học cùng lĩnh vực. Hiện nay việc tìm chỉ số H của bất cứ nhà khoa học học nào đều rất đơn giản nhờ trang web của Scopus.

5.  Một vài lưu ý khi trình bày bài báo trong các tạp chí khoa học

Gần đây, sau khi làm việc với 27 HĐCDGS ngành, liên ngành để tính điểm bài báo được đăng trong các tạp chí khoa học và tính điểm sách khoa học của các ứng viên giáo sư, phó giáo sư, Văn phòng HĐCDGSNN xin nêu lên một số nhận xét bước đầu như sau:

Cho đến nay, theo yêu cầu của HĐCDGSNN, hầu hết các tạp chí khoa học của nước ta, nơi đăng những bài báo khoa học của các ứng viên, đã được đăng ký mã số chuẩn quốc tế cho xuất bản phẩm nhiều kỳ ISSN. HĐCDGSNN đã quy định từ năm 2012 trở đi chỉ những bài báo khoa học được đăng trong các tạp chí có chỉ số ISSN mới được các hội đồng chức danh giáo sư các cấp xem xét, tính điểm. Xin lưu ý thêm rằng, trong Thông tư số 10/2009/TT-BGDĐT ngày 07 tháng 5 năm 2009 về Quy chế đào tạo trình độ tiến sĩ và trong Thông tư sửa đổi, bổ sung, số 05/2012/TT-BGDĐT ngày 15 tháng 02 năm 2012, Bộ GD-ĐT cũng đã quy định, khi nghiên cứu sinh bảo vệ luận án tiến sĩ, nếu có những bài báo khoa học được đăng ở trong nước, thì chỉ được sử dụng những bài báo đã được công bố trên các tạp chí mà HĐCDGSNN tính điểm (xem “Văn bản pháp quy và tài liệu hướng dẫn về việc xét công nhận đạt tiêu chuẩn chức danh GS, PGS năm 2012” của HĐCDGSNN). Bộ GD-ĐT cũng đã khuyến khích nghiên cứu sinh đăng bài trên các tạp chí khoa học quốc tế có uy tín được liệt kê tại địa chỉ http://science.thomsonreuters.com/mjl/.

Theo thông lệ quốc tế thì khi một bài báo khoa học được đăng trên tạp chí thường kèm theo các thông tin sau đây: Ngày tòa soạn nhận được bài báo /received, ngày phản biện đánh giá, yêu cầu sửa chữa lại bài báo (nếu có)/revised, ngày bài báo được đăng/accepted for publication, tóm tắt bài báo/summary/abstract (nếu bài báo được viết bằng tiếng Việt thì nên có tóm tắt bằng tiếng Anh), các mã số phân loại chuyên ngành của bài báo/subject classification, các từ khóa trong bài báo/keywords, tài liệu tham khảo khi viết bài báo/references,... Văn phòng HĐCDGSNN kiến nghị Hội đồng Chức danh giáo sư các cấp: Để tiếp cận các quy chuẩn quốc tế, trong một tương lai gần, chỉ nên xem xét những bài báo khi được đăng ở trong nước đã có đủ các thông tin nêu trên. Mặc dù chúng ta biết rằng một bài báo khoa học được đăng ở trong nước với đầy đủ các thông tin như trên chưa hẳn chất lượng khoa học đã cao.

Lời cám ơn: Trong khi chuẩn bị tài liệu này, chúng tôi đã nhận được những góp ý và bổ sung rất có giá trị của GS Phạm Duy Hiển và GS Nguyễn Hữu Đức. Phần nói về Scopus và Scimago trong bài này là nhờ đóng góp của GS Nguyễn Hữu Đức.

TÀI LIỆU THAM KHẢO

1. Phạm Duy Hiển, A comparative study of research capabilities of East Asian countries and implications for Vietnam, High Educ., (Springer), Vol. 60, p. 615-626, 2010.

2. Phạm Duy Hiển, Nguyễn Văn Tuấn, Nguyễn Hữu Đức, Phạm Đức Chính, thông qua các đường link:

http://vietsciences.free.fr/khaocuu/congtrinhkhoahoc/khoahocvadaihocvn.htm),

http://www.ykhoanet.com/binhluan/nguyenvantuan/071229_nguyenvantuan-nguyendinhnguyen_chatluong-nckh-vietnam.htm), http://www.pnas.org/cgi/content/abstract/102/46/16569,

3. http://en.wikipedia.org/wiki/H-index.

4. Nguồn thông tin từ Trung tâm ISSN Việt Nam, Cục Thông tin Khoa học và Công nghệ Quốc gia, Bộ Khoa học và Công nghệ và từ Cục Xuất bản, Bộ Thông tin và Truyền thông.

5. http://science.thomsonreuters.com/cgi-bin/jrnlst/jlsubcatg.cgi?PC=K

6. http://science.thomsonreuters.com/cgi-bin/jrnlst/jlsubcatg.cgi?PC=D

Công cụ thực nghiệm OCR!

Một số cộng cụ sử dụng trong quá trình thực nghiệm;
- Xử lý ảnh: OpenCv, leptonica, AForge.Imaging (cái này khác tuyệt với)
Thư viện Kmean, clustering :
http://www.alglib.net/commercial.php
Thư viện mọi thứ trọng một về machine learning
http://www.extremeoptimization.com/Default.aspx
Nếu làm SVM không thể quên:
http://www.csie.ntu.edu.tw/~cjlin/libsvm/
À, còn cái này nữa:
http://image.diku.dk/shark/sphinx_pages/build/html/index.html
Supervised learning
Linear discriminant analysis (LDA), Fisher–LDA
Naive Bayes classifier (supporting generic distributions)
Linear regression
Support vector machines (SVMs) for one-class, binary and true multi-category classification as well as regression; includes fast variants for linear kernels.
Feed-forward and recurrent multi-layer artificial neural networks
Radial basis function networks
Regularization networks as well as Gaussian processes for regression
Iterative nearest neighbor classification and regression
Decision trees and random forests
Unsupervised learning
Principal component analysis
Restricted Boltzmann machines (including many state-of-the-art learning algorithms)
Hierarchical clustering
Data structures for efficient distance-based clustering
Evolutionary algorithms
Single-objective optimization (e.g., CMA–ES)
Multi-objective optimization (in particular, highly efficient algorithms for computing as well as approximating the contributing hypervolume)
Fuzzy systems
Basic linear algebra and optimization algorithms

Single Sign On Solution

Với hệ thống có nhiều website và application thì việc sử dụng Single Sign On (SSO) là khá cần thiết nhằm đem lại nhiều thuận tiện cho người dùng và tăng tính năng bảo mật.
SSO chỉ được triển khai sau khi đã xây dựng được hệ thống xác thực và phân quyền. SSO có nhiệm vụ cung cấp cho người dùng quyền truy cập nhiều tài nguyên Web, Applications trong phạm vi cho phép chỉ với một lần đăng nhập (xác thực). Nói thêm về Phân quyền (Access Control), có 2 Rules chính:

• Authentication: Là quá trình để định danh một người dùng có hợp lệ hay không. (Thường thể hiện qua một form đăng nhập)
• Authorization: Là quá trình kiểm chứng một người dùng đã được xác thực có đủ quyền truy cập vào tài nguyên (mà người dùng) yêu cầu hay không. Tài nguyên yêu cầu có thể phụ thuộc vào Policy domain (cấp quyền theo domain) hoặc một policy đặc biệt nào đó (ví dụ cấp quyền theo cấp).

SSO có thể được sử dụng dưới các dạng:

1. Single Domain: Khi xác thực thành công vào domain.com, người dùng đồng thời được xác thực vào các sub-domain.domain.com tồn tại.
2. Multi Domain: Khi xác thực thành công vào facebook.com, người dùng đồng thời được xác thực vào example.com
3. Applications vs Third-Party Products: ví dụ SSO giữa Oracle Access Manager và IBM WebSphere Application Server

Ở 2 dạng đầu tiên, SSO thường sử dụng Cookie để nhận diện, webserver (hay webgate) gửi cookie đã được mã hóa cho browser đã xác thực thành công, cookie này sẽ là chìa khóa sử dụng cho các xác thực tới các tài nguyên khác hoặc cho các xác thực có cùng cấp.
Phần Cookie được mã hóa có thể bao gồm các thông tin: session, distinguished name của người dùng đã xác thực thành công, IP của client đã yêu cầu, thời điểm khởi tạo cookie, thời điểm sửa đổi cookie.. các thành phần không mã hóa của cookie có thể bao gồm: thời gian expired, domain hoạt động, SSL/ Httponly…
Thuật toán mã hóa được recommend hiện nay là AES,  bên cạnh là các thuật toán kém bền vững hơn nhưng thông dụng như MD5-salt, RC4, RC6 vẫn được sử dụng phổ biến trong các mã hóa cookie/ session.

• Single Domain SSO

Cookie Path được cấu hình để dùng chung cho mọi subdomain: .domain.com (bao gồm dấu . ở đầu)

Mô hình của Oracle® Access Manager

• Multi Domain SSO

Multi Domain SSO cho phép người dùng truy cập vào nhiều domains/hosts sau 1 lần đăng nhập. Một ứng dụng xác thực chính sẽ cung cấp các cookie hợp lệ cho mỗi domain.Chẳng hạn người dùng truy cập vào gmail.com, khi đó toàn bộ services của Google, như Google.com, Picasa, Blogspot… đều nhận diện tính xác thực cho người dùng đó.
Tuy nhiên cookie không thể được thiết đặt cho across domains do Policy bảo mật của hầu hết browser, do đó một domain chính sẽ được chọn để xác thực ở mọi quy trình, gọi chung là master domain. Với mỗi domain khác mà người dùng thực hiện quá trình xác thực, mỗi webgate của hệ thống đó sẽ redirect tới master domain.
Master domain sẽ hoạt động như quy trình của Single Domain SSO, nó chính là *proxy* để truyền tải cookie hợp lệ về cho mỗi domain có yêu cầu xác thực.

Mô hình của Oracle® Access Manager

Hoạt động

1. Ta thiết đặt master domain, login-service.domain.com.
2. Mỗi một domain nằm trong group SSO đều có script login riêng.
3. Mọi hệ thống trên mỗi domain đều sử dụng chung Session Database.
4. Khi mỗi Client yêu cầu người dùng xác thực, Webgate của nó sẽ redirects tới master domain có chứa login service. Nếu người dùng chưa đăng nhập, master domain sẽ triệu gọi script login của client để thực hiện việc login vào master domain. Khi người dùng đã xác thực, một session sẽ được tạo trong database và master domain sẽ cung cấp session id cho client yêu cầu để có thể tạo cookie theo session đó.

Notes:

• Các thuật toán mã hóa session. session id phải được dùng chung (RFC 4122)
• Master service chỉ xử lý & redirect tới những domain nằm trong whilelist
• Các domain có thể ở nhiều dạng khác nhau, login.domain.com, domain.com/service, client.abc.com…

Logout
Đây là quá trình quan trọng vì mỗi quá trình logout ở một client chỉ có hiệu lực với cookie của client đó, cần thiết đặt một timeout phù hợp cho cookie hay thiết đặt cơ chế clear cookie ở mọi domain liên quan (chậm chạp), có thể xóa luôn session ở database nhưng lưu ý session có thể tạo lại bởi tính năng Ghi nhớ đăng nhập.

OAuth là gì?

Bài viết này dành cho những người chưa hiểu cơ bản về OAuth và Single Sign On.

OAuth là gì? Đó là câu hỏi không dễ đối với những người chưa từng làm việc với SSO (Single Sign On). Thực ra thì Single Sign On không liên quan gì mấy đến nội dung của OAuth. Tuy nhiên chúng hay đi liền với nhau. Vì vậy cũng phải có sự phân biệt cho khỏi nhầm lẫn.

1. Single Sign On là việc bạn có thể đăng nhập vào một website (như google.com) và sử dụng đăng nhập đó trên các website khác.
• Vì vậy SSO là một tiện ích
• Thường được sử dụng trên các website liên quan mật thiết đến nhau
• Tiện ích SSO có nhiều phương pháp để thực hiện, SAML là một trong các phương pháp đó
2. OAuth là phương pháp chia sẻ tài nguyên giữa các ứng dụng mà không phải đưa ra “giấy thông hành” là username và password.
• Do đó, OAuth là một phương pháp
• Thường được sử dụng trên các website … chả liên quan gì nhau (thực ra là có liên quan đấy, nhưng về mặt bản chất chúng có thể hoạt động mà chẳng cần gì đến nhau, việc kết nối là để xin chút tài nguyên thôi).

Ngoài ra, bạn cũng phải phân biệt giữa hai từ Authorization và Authentication. Từ thứ 2 đơn giản là “đăng nhập” hay không, còn từ thứ nhất là “có quyền” hay không. Cần chú ý chúng khác nhau nhiều lắm, đôi khi bạn chẳng cần “đăng nhập” bạn cũng có thể “có quyền”. Ý của tôi ở đây là Authentication thường liên quan đến việc bạn phải “đăng nhập” vào hệ thống. Còn Authorization tức “có quyền” trên tài nguyên hệ thống hay không thì bạn phải yêu cầu chủ thể của tài nguyên cho phép bạn.

Nói vậy thì hơi lan man, bạn có thể bỏ qua đừng suy nghĩ gì về đoạn giải thích như đánh đố trên.

Xin được đi chi tiết hơn về OAuth, nội dung của nó thì không mới, các hãng lớn như Google, Aol, Yahoo… đều có các phương pháp Authorization của riêng mình. Nhưng nó khiến các bên thứ ba khó khăn khi tích hợp với họ. Vì vậy họ họp nhau lại để tạo ra chuẩn Open Authorization.

1. Bắt đầu với Authorization, cụ thể là OAuth bạn phải phân biệt được những bên liên quan như sau

• Client: là ứng dụng (chú ý là một ứng dụng, có thể là ứng dụng Desktop, cũng có thể là website của bạn như http://www.youbrainy.com
  ), muốn có quyền sử dụng tài nguyên của Server
• Server: là một ứng dụng khác,  chẳng hạn như google.com.
• You: chính bạn, bạn có tài nguyên trên Server và bạn muốn cho Client quyền sử dụng nó

Tóm lại: OAuth là phương pháp để Client sử dụng được tài nguyên của You bên phía Server

2. Phân biệt hai loại OAuth

• 2-legged OAuth: là kiểu Authorization trong đó vai trò của You và Client là như nhau. Tức là Client chính là You của Server. Đó là kịch bản Client-Server thông thường.
• 3-legged OAuth: là kiểu Authorization trong đó You và Client là phân biệt. Client muốn You chia sẻ tài nguyên đã có bên phía Server.

3. Cách OAuth hoạt động

3.1. 2- legged OAuth

1. Client đăng ký sử dụng dịch vụ với Server
2. Server cho Client
• CONSUMER_KEY
• CONSUMER_SECRET_KEY
3. Client sử dụng các keys trên để thực hiện Authorization

3.2. 3- legged OAuth

1. Client đăng ký sử dụng dịch vụ với Server
2. Server cho Client
• CONSUMER_KEY
• CONSUMER_SECRET_KEY
3. You có tài nguyên ở Server
4. You sử dụng dịch vụ ở Client, Client yêu cầu You cho phép khai thác tài nguyên của You ở Server
5. Client yêu cầu Server gửi REQUEST_TOKEN cho You
6. Client chuyển You đến Server Authentication
7. You đăng nhập vào Server, Server hỏi You có muốn chia sẻ quyền khai thác dữ liệu cho Client hay không
8. You đồng ý, Server chuyển You về Client kèm theo ACCESS_TOKEN
9.  Client sử dụng ACCESS_TOKEN để thực hiện thao tác trên các tài nguyên của You thuộc Server

4. Chú ý khi cài đặt với PHP

1. Các trang tích hợp OAuth phần lớn hỗ trợ thư viện để bạn có thể dễ dàng cấu hình OAuth
2. Nếu trong tình huống xấu, bạn chính là người cung cấp dịch vụ và muốn cung cấp mã nguồn tích hợp OAuth với dịch vụ của bạn. Thì bạn phải code rùi. Tất nhiên đây là trường hợp chủ động
3. Nếu bên cung cấp dịch vụ ỉm đi, không cho bạn cái gì sất. Bạn phải code phần client chẳng hạn. Bạn nên tìm hiểu các thư viện sẵn có để học hỏi. Như Zend_OAuth chẳng hạn.

5. Tài liệu

http://oauth.net/core/1.0/

Single Sign On Solution

Với hệ thống có nhiều website và application thì việc sử dụng Single Sign On (SSO) là khá cần thiết nhằm đem lại nhiều thuận tiện cho người dùng và tăng tính năng bảo mật.

SSO chỉ được triển khai sau khi đã xây dựng được hệ thống xác thực và phân quyền. SSO có nhiệm vụ cung cấp cho người dùng quyền truy cập nhiều tài nguyên Web, Applications trong phạm vi cho phép chỉ với một lần đăng nhập (xác thực). Nói thêm về Phân quyền (Access Control), có 2 Rules chính:

• Authentication: Là quá trình để định danh một người dùng có hợp lệ hay không. (Thường thể hiện qua một form đăng nhập)
• Authorization: Là quá trình kiểm chứng một người dùng đã được xác thực có đủ quyền truy cập vào tài nguyên (mà người dùng) yêu cầu hay không. Tài nguyên yêu cầu có thể phụ thuộc vào Policy domain (cấp quyền theo domain) hoặc một policy đặc biệt nào đó (ví dụ cấp quyền theo cấp).

SSO có thể được sử dụng dưới các dạng:

1. Single Domain: Khi xác thực thành công vào domain.com, người dùng đồng thời được xác thực vào các sub-domain.domain.com tồn tại.
2. Multi Domain: Khi xác thực thành công vào facebook.com, người dùng đồng thời được xác thực vào example.com
3. Applications vs Third-Party Products: ví dụ SSO giữa Oracle Access Manager và IBM WebSphere Application Server

Ở 2 dạng đầu tiên, SSO thường sử dụng Cookie để nhận diện, webserver (hay webgate) gửi cookie đã được mã hóa cho browser đã xác thực thành công, cookie này sẽ là chìa khóa sử dụng cho các xác thực tới các tài nguyên khác hoặc cho các xác thực có cùng cấp.

Phần Cookie được mã hóa có thể bao gồm các thông tin: session, distinguished name của người dùng đã xác thực thành công, IP của client đã yêu cầu, thời điểm khởi tạo cookie, thời điểm sửa đổi cookie.. các thành phần không mã hóa của cookie có thể bao gồm: thời gian expired, domain hoạt động, SSL/ Httponly…

Thuật toán mã hóa được recommend hiện nay là AES,  bên cạnh là các thuật toán kém bền vững hơn nhưng thông dụng như MD5-salt, RC4, RC6 vẫn được sử dụng phổ biến trong các mã hóa cookie/ session.

• Single Domain SSO

Cookie Path được cấu hình để dùng chung cho mọi subdomain: .domain.com (bao gồm dấu . ở đầu)

Mô hình của Oracle® Access Manager

• Multi Domain SSO

Multi Domain SSO cho phép người dùng truy cập vào nhiều domains/hosts sau 1 lần đăng nhập. Một ứng dụng xác thực chính sẽ cung cấp các cookie hợp lệ cho mỗi domain.Chẳng hạn người dùng truy cập vào gmail.com, khi đó toàn bộ services của Google, như Google.com, Picasa, Blogspot… đều nhận diện tính xác thực cho người dùng đó.

Tuy nhiên cookie không thể được thiết đặt cho across domains do Policy bảo mật của hầu hết browser, do đó một domain chính sẽ được chọn để xác thực ở mọi quy trình, gọi chung là master domain. Với mỗi domain khác mà người dùng thực hiện quá trình xác thực, mỗi webgate của hệ thống đó sẽ redirect tới master domain.

Master domain sẽ hoạt động như quy trình của Single Domain SSO, nó chính là *proxy* để truyền tải cookie hợp lệ về cho mỗi domain có yêu cầu xác thực.

Mô hình của Oracle® Access Manager

Hoạt động

1. Ta thiết đặt master domain, login-service.domain.com.
2. Mỗi một domain nằm trong group SSO đều có script login riêng.
3. Mọi hệ thống trên mỗi domain đều sử dụng chung Session Database.
4. Khi mỗi Client yêu cầu người dùng xác thực, Webgate của nó sẽ redirects tới master domain có chứa login service. Nếu người dùng chưa đăng nhập, master domain sẽ triệu gọi script login của client để thực hiện việc login vào master domain. Khi người dùng đã xác thực, một session sẽ được tạo trong database và master domain sẽ cung cấp session id cho client yêu cầu để có thể tạo cookie theo session đó.

Notes:

• Các thuật toán mã hóa session. session id phải được dùng chung (RFC 4122)
• Master service chỉ xử lý & redirect tới những domain nằm trong whilelist
• Các domain có thể ở nhiều dạng khác nhau, login.domain.com, domain.com/service, client.abc.com…

Logout

Đây là quá trình quan trọng vì mỗi quá trình logout ở một client chỉ có hiệu lực với cookie của client đó, cần thiết đặt một timeout phù hợp cho cookie hay thiết đặt cơ chế clear cookie ở mọi domain liên quan (chậm chạp), có thể xóa luôn session ở database nhưng lưu ý session có thể tạo lại bởi tính năng Ghi nhớ đăng nhập.

PORTAL - Cơ chế Single Sign On - 2

Central Authenticate Service 

- Giới thiệu
- Triển khai
- Các giải pháp bảo mật ứng dụng

C - Central Authenticate Service (CAS)
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.

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

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
oKiể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.
oNhữ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.
oINVALID_REQUEST: Không tìm thấy tham số cần tìm trong request.
oINVALID_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.
oINVALID_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.
oINTERNAL_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
oCung cấp proxy ticket đến những service, lấy PTG thông qua /proxyValidate hoặc /serviceValidate
oNhữ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

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

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.
oNgườ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.
oNế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.
oCAS 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 - 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
oNgườ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
oNgườ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
oXá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

Một số công cụ cơ bản trong máy tính!

Tài liệu: http://www.mediafire.com/download/li9bt2e7nvcttzw/TaiLieul.rar
Công cụ tổng hợp: http://www.mediafire.com/folder/b59rnn0h8y0e8/Soft
Cụ thể:
1. Ẩn IP: http://www.mediafire.com/?cb34zvduftdkqro
2. Phần mềm khôi phục dữ liệu GetDataback: http://www.mediafire.com/?wk87th4g6b5g9q1
3. Hiển thị file ẩn: http://www.mediafire.com/?6497le7iv2j3poh
4. Phần mềm mã hóa  dữ liệu TrueCrypt: http://www.mediafire.com/?7480p86f9kklw3e
5. Convert các file văn bản: http://www.mediafire.com/?25eptbyfvb6peum
Link trên Upfile.vn
 1. AntiVirus: http://upfile.vn/9maC
2. Convert file văn bản: http://upfile.vn/9maD
3. Font chữ: http://upfile.vn/9maF
4. Khôi phục dữ liệu GetDataBack: http://upfile.vn/9maG
5. Ẩn địa chỉ IP: http://upfile.vn/9maH
6. Hiện file ẩn: http://upfile.vn/9maI
7. Mã hóa TrueCrypt: http://upfile.vn/9maJ

Hướng dẫn sao lưu và phục hồi dữ liệu blog

Hướng dẫn vài đặt và sửu dụng phần mềm mã hóa TrueCrypt