Configure IIS 7 as Reverse Proxy

By default, Information Portal uses Apache (http://en.wikipedia.org/wiki/Apache_HTTP_Server) as a web server. It is included in the Information Portal installation package and automatically configured to be accessed by the URL like: http://server:3141.
You can configure IIS 7 to work as a web server for Information Portal if it is required to use IIS for all web applications by the company policy. The following are additional options available in IIS 7:

• Configure SSL encryption
• Configure a host-header with the default port
• Configure load distribution
• Use automatic Windows updates to always have IIS in the most secured state.

Configuration includes three steps:

1. Configure IIS 7 as a reverse proxy (http://en.wikipedia.org/wiki/Reverse_proxy). This means that all requests from users are sent to IIS 7 site and then redirected to the Portal Apache server. The response from Apache goes back to IIS, and then IIS sends it back to the user. We use Application Request Routing Module http://www.iis.net/download/ApplicationRequestRouting to implement this process.
2. To avoid the direct access to Information Portal via Apache server, disable listening external requests. Apache is hidden for all users since listening external requests are disabled.
3. Reconfigure the Information Portal SharePoint Integration feature to point to a new IIS site.

Step 1. Configure IIS 7 as Reverse Proxy

The solution is based on the standard IIS extension - the Application Request Routing module. Install it on the server hosting Information Portal and IIS 7. The Application Request Routing module can be downloaded at http://www.iis.net/download/ApplicationRequestRouting.
After the Application Request Routing (ARR) module has been installed, it should be configured to act as a proxy server (this functionality is not enabled by default). In IIS Manager, highlight the Application Request Routing Cache feature and click Open Feature in the Actions pane.

Click Server Proxy Settings in the Actions pane.
Tick the Enable proxy checkbox, and then click Apply. Leave all the default values in place.

Next, configure the URL Rewrite rule, so that IIS knows what to do with requests which you want to forward to Information Portal Apache. Click a site which is supposed to be used for Information Portal. If you do not have any site, create it. In our example, a test site with the URL http://atsp2010:82 is used. Highlight the URL Rewrite icon, and then click Open Feature in the Actions pane.

In the URL Rewrite feature, click Add Rules in the Actions Pane.
In the Add Rule(s) dialog box, select Blank rule and click OK.
In the Edit Inbound Rule feature, specify the new rule name and type .* in the Pattern dialog box. The new rule should default to using Regular Expressions (if it does not, ensure that you select this option). In the Action section of the Edit Inbound Rule feature, ensure that the Action type is set to Rewrite and then enter http://localhost:3141/{R:0} in the Rewrite URL dialog box as shown below. Click Apply to create the new rule.
We assume that Information Portal is installed on port 3141 (default), so http://locahost:3141 is the Information Portal Apache server URL.

Now you can test the URL: http://atsp2010:82. It displays the Information Portal Enterprise report ? the same as the http://localhost:3141 URL.
SSL can be configured on this IIS site. For more information, see the following article: http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7.

Step 2. Configure Apache to be Localhost Only

Now disable the direct access to Information Portal via Apache server.
Perform the following:

1. Open C:\Program Files (x86)\Quest Software\Site Administrator for SharePoint\SharePoint Information Portal\Python25\conf\httpd.conf in notepad. (here we assume that the product is installed in the default path on x64 OS).
2. Change ServerName atsp2010:3141 to ServerName 127.0.0.1:3141 (assuming that atsp2010 is the name of this server).
3. Change Listen 3141 to Listen 127.0.0.1:3141.
   The modified httpd.config file will look as follows:
   ServerRoot “C:\Program Files (x86)\Quest Software\Site Administrator for SharePoint\SharePoint Information Portal\Python25”
   ServerName 127.0.0.1:3141
   ServerSignature Off
   ServerTokens Prod
   DocumentRoot “C:\Program Files (x86)\Quest Software\Site Administrator for SharePoint\SharePoint Information Portal\Python25”
   Listen 127.0.0.1:3141
   ...
   
4. Restart the Quest.InfoPortal.WebAccess service.

Verify that http://atsp2010:3141 does not work from other servers (atsp2010 is the name of the server hosting Information Portal. Replace it with your server name).
Verify that http://atsp2010:82 works.
Now you have Information Portal installed with the IIS web front-end server.

Step 3. Reconfigure Information Portal SharePoint Integration Feature

As the Information Portal URL has been changed to http://atsp2010:82, it is required to reconfigure the SharePoint Integration feature.
Perform the following:

1. Run cmd.exe on the server hosting Information Portal.
2. Make the C:\Program Files (x86)\Quest Software\Site Administrator for SharePoint\SharePoint Information Portal\SPIntegration folder current.
3. Make sure that Windows SharePoint Services Administration (SharePoint 2007) or SharePoint 2010 Administration (Sharepoint 2010) service is started on the front-end.
4. Run the following command:
   ..\IronPython26\ipy64.exe wsp_install.py http://atsp2010:82
   
5. Make sure the output does not contain errors. The process successfully completed should look like:
   1/28/2011 8:57:50 PM: Sharepoint Integration install [‘wsp_install.py’, ‘http://atsp2010:82’]
   1/28/2011 8:57:53 PM: Generating wsp solution in .\\SPIntegrationFeature for http://atsp2010:82
   1/28/2011 8:57:55 PM: setup solution: .\\SPIntegrationFeature\SPIntegrationFeature.wsp
   1/28/2011 8:57:55 PM: stop running jobs
   1/28/2011 8:57:56 PM: remove old solution
   1/28/2011 8:57:59 PM: add solution
   1/28/2011 8:58:09 PM: deploy solution
   
6. Ensure that SharePoint sites have the Site Administrator Reports section containing the links to the Information Portal reports in the Site Settings. Try to open these links. In SharePoint 2010, it looks as follows:
   
   
   sahelp.sharepointforall.com

Hệ thống một cửa điện tử và dịch vụ công trực tuyến

Hệ thống một cửa điện tử

VSDOneStop là giải pháp phần mềm hành chính một cửa  điện tử được ứng dụng nhằm tin học hóa các giao dịch giữa tổ chức, công dân với cơ quan hành chính nhà nước theo cơ chế “một cửa” quy định tại Quyết định số 93/2007/QĐ-TTg ngày 22/6/2007 của Thủ tướng Chính phủ. Giao dịch được tin học hóa bao gồm từ hướng dẫn, tiếp nhận giấy tờ, hồ sơ, giải quyết đến trả kết quả được thực hiện tại một đầu mối là bộ phận tiếp nhận và trả kết quả của cơ quan hành chính nhà nước.

Hệ thống một cửa điện tử VSDOneStop do Công ty VSD xây dựng và phát triển với nhiều kênh truy cập là điểm duy nhất tiếp nhận hồ sơ và trả kết quả cho người dân và doanh nghiệp khi thực hiện thủ tục hành chính công bao gồm trực tiếp hoặc trên môi trường mạng internet.

Đối tượng áp dụng là các đơn vị cấp xã, cấp huyện như quận, huyện, thị xã, thành phố trực thuộc tỉnh/thành phố trực thuộc Trung ương. Các sở ngành, đơn vị chức năng trực thuộc các Bộ/tỉnh.

Các chức năng nổi bật của hệ thống

1. Tiếp nhận hồ sơ trực tiếp tại bộ phận một cửa

2. Tiếp nhận hồ sơ trực tuyến

3. Cho phép in phiếu hẹn nhiều lần đối với các thủ tục phải hẹn công dân / tổ chức nhiều lần

4. Quản lý hồ sơ
Cho phép lãnh đạo cơ quan, lãnh đạo phòng ban xử lý hoặc phân xử lý hồ sơ ( phối hợp hoặc không phối hợp).

Cho phép xem nhật ký quá trình xử lý hồ sơ

Cho phép xử lý thay lãnh đạo

5. Cho phép tìm kiếm hồ sơ và thống kê báo cáo theo nhiều tiêu chí

6. Cho phép quét / đính kèm các quyết định khi trả kết quả

7. Nhắc việc - thông báo và thống kê cho người dùng các hồ sơ chờ phải xử lý

Dịch vụ công trực tuyến

1. Cung cấp các hướng dẫn thủ tục hành chính cho công dân, tổ chức.

2. Cho phép công dân/ tổ chức gửi hồ sơ trực tuyến

3. Cho phép công dân/ tổ chức tra cứu kết quả hồ sơ khi gửi trực tiếp tại bộ phận một cửa hoặc gửi trực tuyến

Mọi chi tiết xin liên hệ:
Hỗ trợ kỹ thuật:

• Ngô Sinh Nguyên - 04.62737311 (nsnguyen@vsd.com.vn)
• Phùng Quốc Hoàn - 04.62737311 (pqhoan@vsd.com.vn)

Hỗ trợ kinh doanh:

• Nguyễn Quang Tuấn - 04.62737300,  0912.068.823 (nqtuan@vsd.com.vn)

Phần mềm quản lý hộ tịch

Bài toán “Quản lý hộ tịch” được đặt ra nhằm hỗ trợ cho công tác quản lý của cán bộ hộ tịch giữa các cấp và hỗ trợ lãnh đạo trong công tác quản lý về vấn đề hộ tịch trên địa bàn tỉnh Việc thực hiện bài toán này góp phần phục vụ nhân dân được tốt hơn, rút ngắn thời gian giải quyết công việc, mang lại hiệu quả nhất định trong việc trao đổi thông tin, nâng cao hiệu quả công tác quản lý hộ tịch và tạo điều kiện thiết lập hệ thống thông tin liên kết, thống nhất giữa Sở Tư pháp và các đơn vị hành chính quận - huyện, phường - thị xã. 


  Để giải quyết bài toán này, đến nay đã có nhiều phần mềm do một số công ty xây dựng và phát triển trên một số công cụ khác nhau. Các ứng dụng này đã đem lại một số hiệu quả ban đầu. Tuy nhiên để đáp ứng được các công tác hộ tịch thì các phần mềm này còn một số hạn chế: Chưa in được đầy đủ các biểu mẫu hộ tịch, các biểu mẫu đã in được chưa theo nghị định mới của chính phủ (Nghị định 158/2005/NĐ-CP) hoặc vấn đề in ra phôi còn hạn chế.Nói chung chưa đáp ứng được theo nghị định 158/2005/NĐ-CP.Ngoài ra do cơ sở hạ tầng ở các địa phương thấp chưa đáp ứng được cho việc cài đặt ứng dụng. Trình độ công nghệ thông tin của đội ngũ cán bộ tư pháp ở các cấp xã/ phường không đồng đều.

Để khắc phục những vấn đề trên việc lựa chọn công cụ phát triển cho phù hợp với từng cấp sử dụng là vấn đề quan trọng nhằm đáp ứng tốt nhất cho người dùng, dễ dàng triển khai và phát triển khi có thay đổi hoặc mở rộng chức năng của chương trình. Vì thế căn cứ vào những quy định của nghị định 158/2005/NĐ-CP, căn cứ vào thực tế cơ sở hạ tầng của các địa phương,..chúng tôi lựa chọn giải pháp:

Hệ thống thông tin Quản lý Hộ tịch bao gồm có 3 phân hệ :

• Phân hệ Quản lý Hộ tịch cấp Xã

• Phân hệ Quản lý Hộ tịch cấp Huyện

• Phân hệ Quản lý Hộ tịch cấp Sở

Mọi chi tiết xin liên hệ:
Hỗ trợ kỹ thuật:

Ngô Sinh Nguyên - 04.62737311 (nsnguyen@vsd.com.vn)
Phùng Quốc Hoàn - 04.62737311 (pqhoan@vsd.com.vn)

Hỗ trợ kinh doanh:

Nguyễn Quang Tuấn - 04.62737300,  0912.068.823 (nqtuan@vsd.com.vn)

Hệ thống QL Cụm, điểm Công nghiệp

(Quản lý cụm điểm công nghiệp, phần mềm quản lý cụm điểm công nghiệp)

       Cùng với sự phát triển của nền kinh tế nước ta, các công ty, doanh nghiệp ngày càng nhiều và tập hợp thành các Khu, cụm, điểm công nghiệp trên địa bàn các tỉnh. Đi cùng với nó là các dự án được đầu tư mạnh mẽ, các cụm, điểm công nghiệp ngày càng được mở rộng hơn. Để tăng cường hiệu quả trong công tác quản lý nhà nước về cụm, điểm công nghiệp, dự án đầu tư Công ty cổ phần công nghệ VSD đã nghiên cứu, khảo sát, và xây dựng “Hệ thống quản lý Cụm, điểm công nghiệp” nhằm mục đích nâng cao ứng dụng công nghệ thông tin trong cơ quan hành chính nhà nước.

     “Hệ thống quản lý Cụm, điểm công nghiệp” trực tiếp do Phòng Công nghiệp trực thuộc Sở công thương của các tỉnh quản lý. Hệ thống được ứng dụng trên toàn tỉnh, với đầu mối là Trung tâm Khuyến công và Xúc tiến thương mại thuộc Sở công thương và ứng dụng đến các phòng Công thương, Kinh tế các quận/huyện, thành phố, Trung tâm Phát triển cụm công nghiệp trên địa bàn tỉnh.

     Một số tính năng chính của “Hệ thống quản lý Cụm, điểm công nghiệp”

• Quản lý nội dung website
• Quản lý các tài liệu văn bản
• Quản lý thông tin về doanh nghiệp – nhà đầu tư
• Quản lý Cụm, điểm công nghiệp
• Quản lý các dự án
• Tìm kiếm doanh nghiệp – nhà đầu tư, tìm kiếm Cụm điểm công nghiệp, tìm kiếm các dự án.
• In báo cáo thống kê về thông tin các doanh nghiệp, thông tin các dự án, báo cáo tổng hợp theo kỳ (tháng, quý, 6 tháng, 1 năm).....

     Một số hình ảnh:

 Giao diện tổng quan

 Quản lý Cụm, điểm công nghiệp

Hình :  Quản lý thông tin Doanh nghiệp

Báo cáo số liệu định kỳ của doanh nghiệp.

Báo cáo tình hình sản xuất - kinh doanh trong cụm công nghiệp

Mọi chi tiết xin liên hệ:
Hỗ trợ kỹ thuật:

Ngô Sinh Nguyên - 04.62737311 (nsnguyen@vsd.com.vn)
Phùng Quốc Hoàn - 04.62737311 (pqhoan@vsd.com.vn)

Hỗ trợ kinh doanh:

Nguyễn Quang Tuấn - 04.62737300,  0912.068.823 (nqtuan@vsd.com.vn)

Phần mềm Quản lý đối tượng bảo trợ xã hội

Chính sách bảo trợ xã hội là một trong những chính sách xã hội thể hiện tính ưu việt của chế độ ta, là một trong những nội dung cơ bản trong hệ thống an sinh xã hội hiện nay của nước ta. Thực hiện quan điểm, chủ trương, đường lối, chính sách của Đảng và nhà nước về công tác bảo trợ xã hội, trong những năm qua cùng với việc tham mưu tổ chức triển khai thực hiện đồng bộ, có hiệu quả các chính sách trên lĩnh vực Người có công, lĩnh vực lao động thì ở lĩnh vực xã hội, chính sách bảo trợ xã hội cũng được tổ chức thực hiện kịp thời, đồng bộ, đạt được những kết quả quan trọng, đời sống của đối tượng và gia đình được cải thiện hơn trước, tạo được niềm vui, niềm tin và chỗ dựa vững chắc cho đối tượng bảo trợ xã hội, từ đó khẳng định tính đúng đắng về chủ trương, đường lối, chính sách của Đảng và Nhà nước ta.

Trên thực tế, công tác bảo trợ xã hội hiện nay vẫn được quản lý thủ công, không có hiệu quả và tiện ích trong công việc, chính vì vậy, Công ty VSD phát triển sản phẩm "Quản lý đối tượng bảo trợ xã hội", nhằm tin học hóa công việc, tạo ra tính hiệu quả và mang lại nhiều lợi ích cho người sử dụng.

Phần mềm đáp ứng việc:

• Quản lý hồ sơ của các đối tượng thuộc diện bảo trợ xã hội

• Quản lý việc chi trả đột xuất

• Thống kê báo cáo

• Quản lý các danh mục

Mọi chi tiết xin liên hệ:
Hỗ trợ kỹ thuật:

Ngô Sinh Nguyên - 04.62737311 (nsnguyen@vsd.com.vn)
Phùng Quốc Hoàn - 04.62737311 (pqhoan@vsd.com.vn)

Hỗ trợ kinh doanh:

Nguyễn Quang Tuấn - 04.62737300,  0912.068.823 (nqtuan@vsd.com.vn)

Xác thực người dùng và tên ( User authentication and Names)

Chức năng bảo mật cơ bản trong mô hình bảo mật của Domino là xác thực người dùng ( bao gồm Notes clients, các domino server khác, browser và Internet client, và các chương trình phát triển sử dụng Notes API). Trong phần này tôi sẽ nói với các bạn về phần tổng quan xác thực, đặt tên phân cấp người dùng và máy chủ.

Khi một người dùng được xác định là "xác thực", server dựa trên sự hợp lệ của user name để điều khiển truy cập với Server và Database Access Controll Lists.

Trong phần này tôi cũng giới thiệu tổng quan về phân chia tổ chức của bạn ( Organization) thành các đơn vị chức năng ( Organization Unit - OU). OU Certificate ID được tạo từ ID gốc của tổ chức, sau đó được sử dụng để đăng ký người dùng và server

-----> Phần này có một chút tới kiến thức LDAP hoặc AD

ID file được tạo trong suốt quá trình setup first Domino Server

Bạn có thể không nhận ra trong quá trình cài đặt First Server, là bạn đã cài đặt một hệ thống bảo mật cơ bản.

Sử dụng tên của Organization bạn nhập vào, quá trình cài đặt tạo ra duy nhất một Organization Certificate ( chuỗi 1024 bit bao gồm số và ký tự) cho Organization. Được xác định bởi tên, ví dụ "O=VSD"

Cùng với các thông tin khác, quá trình cài đặt thêm Organization Certificate vào Organization Certifier ID file có tên là CERT.ID

Server Setup sử dụng CERT ID để tạo ID cho server và Administrator

Các thông tin về máy chủ và người dùng được thêm vào mỗi file ID, tất cả các file này được đánh dấu hai thứ từ Organization Certifier:

• Tên của Organization, ví dụ "VSD", được nối thêm vào phần tên của server và tài khoản người dùng ( đôi khi còn được gọi là tên phân biệt - Disinguished name).
• Organization Certificate

Chú ý: trong bài hướng dẫn cài đặt lần trước, tôi đã tạo luôn Organization Unit (OU), nên tên của máy chủ và người dùng có dạng CN=Mail/OU=NN/O=COM, CN=ADMIN/OU=NN/O=COM

Nội dung của file ID

Để xem được nội dung của file ID Server hoặc ID User, bật giao diên Domino Administrator lên, di chuyển tới tab chức năng Configuration, chọn Certification\ ID Properties, chọn file ID cần xem

Tab Your Certificate bạn có thể thấy các certficate được thêm vào file ID.
Hình dưới đây thể hiện các thành phần có trong file ID

Bảng dưới đây mô tả hình ảnh trên

Thành phần	Chức năng
User Name	Tên ( người dùng, máy chủ) để Domino quản lý và kiểm tra bảo mật database
Password	Nhấp vào tab Security Basics, nhấp chuột vào Change Password, để thay đổi mật khẩu. Độ khó của mật khẩu được thiết lập lúc đăng ký, và người dùng có thể thay đổi mật khẩu của họ miễn là mật khẩu đủ mạnh. Nếu mật khẩu không đủ mạnh, bạn sẽ gặp một thông báo là nhập một mật khẩu khác mạnh hơn. Người quản trị có thể yêu cầu ( thông qua cài đặt trong Domino Directory) mật khẩu User ID thay đổi trong khoảng thời gian hoặc người dùng bị khóa bởi máy chủ
Expiration Date	Theo mặc định, certificate của Server ID có thời hạn là 100 năm, User ID có thời hạn là 2 năm. Khi bạn đăng ký hoặc gia hạn ID file, bạn có thể thay đổi các thời hạn khác nhau.
Recovery Password(s)	Đây là một lựa chọn phục hồi lại mật khẩu, được thêm vào bởi người quản trị khi mở User ID file nếu quên mật khẩu. Việc khôi phục này, chỉ áp dụng nới Notes User ID và không áp dụng với Server ID, trong trường hợp khác, bạn có thể cấu hình Notes User ID Vault để nhanh chóng khôi phục lại ID và mật khẩu bị mất.
Notes Certificates	Bao gồm 2 certificate, (Notes Multi-purpose, Notes international encryption) và còn lại là certificate từ Certifier : Một từ Organization Certifier.(CERT.ID) Một từ mọi OU certifier (OU.ID) Mỗi certificate gồm có: Tên của Organization hoặc Organization Unit certifier được sử dụng để cấp phát certificate Tên của người dùng hoặc máy chủ mà certificate được cấp phát Private Key và Public key Chữ ký số của certifier để chứng minh quá trình xác thực của Notes Certificate Ngày hết hạn khi certificate không còn hợp lệ
Public Key	Một khóa mã hóa duy nhất được lưu trữ trong file ID, sử dụng trong suốt quá trình xác thực, mã hóa mail gửi tới các Notes Client khác và được lưu trong mail database của người dùng. Public Key có thể được sao chép, gửi mail từ User Security >Your Certificate, hoặc sao chép từ tài liệu user’s Person trong Domino Directory
Private Key	Một khóa mã hóa duy nhất cho người dùng, và được lưu trữ chỉ trong file User ID. Khóa này không thể xem được. Khóa Private được sử dụng để valid người dùng trong quá trình xác thực, cũng có thể dùng: Giải mã mail đã được mã hóa khớp với Public Key Mã hóa mail gửi tới Notes User. Chú ý : Nếu mất User ID và không có bản backup, tất cả các mail đã được mã hóa sẽ không thể được giải mã bởi vì User ID mới có chứa Private Key mới.
Document Encryption Keys	Các khóa mã hóa sử dụng để mã hóa và giải mã document fields. Ví dụ, HR database cho phép người dùng đọc các thông tin tổng quan về người lao động, nhưng trường Salary được mã hóa và chỉ một số người trong công có chìa khóa mã hóa để mã hóa và giải mã trường này.
Internet Certificates	Một option, chứng chỉ X.509 sử dụng để mã hóa với Web server, xác thực user name, mã hóa mail gửi tới internet user. Chứng chỉ này được thêm vào sau khi người dùng được đăng ký.

.

Server ID file: Có mật khẩu hay không có mật khẩu?

Có hay không mật khẩu cho server id file là một chủ đề lớn cần tranh luận. Theo mặc định, server id file không có mật khẩu, điều này làm giảm khả năng bảo mật. Đặt mật khẩu cho server id file  tạo cho server bảo mật hơn và bảo vệ những databases đã được mã hóa. Nhưng bên cạnh đó, bạn phải luôn thường trực tại server khi bạn khởi động nó, thậm chí Domino server khởi động như windows services ( Khà khà, không chạy đi đâu được, vì phải gõ mật khẩu cho file ID Server, thì domino server mới bật lên được).
Để được tốt nhất cả về sự thuận tiện và bảo mật, bạn cần cài đặt thêm một công cụ của hãng thứ ba để bảo mật quá trình khởi động server mà không ảnh hưởng tới Server ID.
Bạn không nên đặt mật khẩu cho server id trong hai trường hợp sau:

• Sử dụng công cụ Domino Admin từ xa để khởi động lại Domino Server
• Sử dụng tính năng tự động phục hồi máy chủ

Cả hai tính năng này có bộ nhớ cache mật khẩu và sử dụng nó khi server khởi động lại.

Xác nhận và xác thực ( Validation and Authentication)

Nhắc lại mô hình bảo mật tôi giới thiệu trong bài trước, khi người dùng Notes thực hiện kết nối vào Domino Server ( hoặc Domino Server này kết nối vào Domino Server khác), việc đầu tiên xảy ra là quá trình xử lý hai pha, validation và authentication. Tại điểm cuối của quá trình, hai bên trust với nhau, và danh tính của người dùng được xác nhận. Điều này đủ để chuyển qua bước tiếp theo trong mô hình bảo mật, bước "Server access list" để so sánh sự hợp lệ của người dùng và server.
Sau đây tôi sẽ mô tả một cách đơn giản quá trình xử lý hai pha khi đồng chí Admin/VSD/COM kết nối vào máy chủ Mail, áp dụng với tất cả các kết nối (LAN, WAN, dial-up,...).
Mọi thứ cần thiết cần thiết để xác nhận và xác thực đều chứa trong file ID của người dùng hoặc server.

Trong pha xác nhận, MAIL server xác định Public Key của đồng chí ADMIN:

1. Notes client gửi tất cả Notes Certfificates trong file admin.id tới MAIL server, bao gồm cả Admin's personal certificate và tất cả certificate của Organization/Organization Unit.
2. MAIL server tìm kiếm certificate /VSD mà Admin gửi, và tìm một certificate có tên giống như vậy trong file ID mà nó quản lý.
3. Sử dụng Public Key của /VSD cert, MAIL server xác định Admin's persional certificate là hợp lệ bởi vì nó giống với /VSD cert
4. MAIL server kết luận Public Key trong Admin's personal cert là hợp lệ.

Pha xác nhận được lặp lại, nhưng đổi chiều

Trong pha xác thực, MAIL server xác định tính hợp lệ định danh của ADMIN:

1. MAIL server sinh ra một số ngẫu nhiên và mã hóa nó sử dụng Admin Public key và gửi nó cho Notes clients.
2. Sử dụng Private ksy chỉ có trong Admin User ID file, Notes giải mã số và gửi lại cho Mail server.
3. Mail server so sánh số ban đầu với số mà mà Notes gửi. Nếu bằng nhau, thì Notes User ID có Private key giống với Public key sử dụng để giải mã thành công.

Pha xác thực được lặp lại, nhưng đổi chiều.
Trong suốt quá trình cài đặt First Domino server, OU cert được sử dụng để đăng ký Administrator user. Miễn là bạn đăng ký người dùng và máy chủ sử dụng OU cert này, thì quá trình xác nhận và xác thực đều được đảm bảo.
Nếu bạn mất  Organization ID, thì bạn gặp vấn đề lớn rồi đấy. Thậm chí nếu bạn tạo một ID giống hệt với Organization  name, bạn sẽ có một tập các khóa mới. Mọi người dùng và máy chủ mới tạo ra bởi ID mới sẽ không thể xác thực được với server hiện tại. Có hai cách giải quyết vấn đề này:

• Tạo mới Organization cert, đăng ký mới người dùng và máy chủ sử dụng ID này. Sau đó cross certify người dùng và máy chủ hiện đang tồn tại.
• Tạo mới Organization ID với tên giống trước hoặc khác, sau đó recertify Notes và Domino ID file.

Tăng cường bảo mật xác thực

Nếu quá trình xác thực hiện tại chưa làm bạn hài lòng, bạn có thể tăng cường khả năng bảo mật của quá trình xác thực bằng cách bắt server so sánh Public key từ Domino Directory trong suốt quá trình xác thực Public key được gửi từ Notes client hoặc server. Vì thế, trong trường hợp gần như không thể, hách cơ hack user id file để có được Public key, với việc kích hoạt tính năng này, khóa phải khớp với khóa được lưu trong Domino Directory.
Để kích hoạt tính năng so sánh key, bạn xem hình dưới

Chú ý: thiết lập này nhằm ngăn chặn người dùng bên ngoài tổ chức có thể cross-certified để có thể truy cập vào máy chủ. Nó còn ngăn chặn người dùng đã xóa khỏi Domino Directory có thể truy cập.
Thiết lập này ko áp dụng với browser client.

Hệ thống phân cấp OU Cert

Trong quá trình cài đặt First Server đã tạo ra Organization Cert ID, và từ ID này tạo ra Server ID và Admin ID tại gốc trong mô hình phân cấp ( cụ thể ở đây là /VSD)
Không hạn chế nếu bạn đăng ký tất cả user và server sử dụng Organization Certifier ID. Nhưng đôi khi, bạn có hàng trăm người dùng Notes, cách tốt nhất là bạn tạo ra một hệ thống phân cấp, để tiện cho việc quản lý, ví dụ:

Các OU cert được tạo ra từ O cert.

Thuận lợi của việc sử dụng Organizational Unit

Những thuận lợi khi bạn chia nhỏ Organization thành các OU là:
Người dùng trùng tên có thể phân biệt qua OU
Người quản tri tại mức OU có thể sử dụng OU ID để đăng ký người dùng và server bên trong tổ chức của mình
Phân quyền truy cập tới máy chủ và database có thể sử dụng ký tự đại diện (*/UB/QN/VSD)

Bài tiếp theo: Đăng ký người dùng và nhóm

Tổng quan về bảo mật trong Domino ( Domino Security overview)

Bảo mật trong Domino rất mạnh mẽ, liên quan tới cơ chế bảo mật nhiều lớp để bảo vệ máy chủ và database tránh khỏi các truy cập không hợp pháp.
Trong phần này, tôi sẽ giới thiệu tổng quan về bảo mật trong Domino, thể hiện cho các bạn theo trình tự truy cập được phần quyền từ mức thấp tới mức cao.

Mô hình bảo mật ( Security Model)

Biểu đồ dưới đây thể hiện một loạt các bước bảo mật thông qua các lớp.

Người dùng phải thỏa mãn các cơ chế bảo mật của Domino - theo chuỗi từ trái qua phải để có thể truy cập vào dữ liệu:

• Authentication: trong suốt quá trình xác thực, người dùng chứng mình - tên của họ được xác thực
• Server access: điều khiển truy cập tới Domino Server dựa trên tên có tồn tại trong Server Access Control List.
• Database access: điều khiển toàn bộ quyền thiết lập tới database trong ACL

Tổng quan về mô hình bảo mật

• Mô hình bảo mật cho Notes Client truy cập tới Domino server giống với cách Domino Server này truy cập tới Domino server khác ( ví dụ như đồng bộ hóa, định tuyến mail, chia sẻ các thông tin về lập lịch, ect), nhưng truy cập Domino theo trình duyệt và các trình Internet client khác (POP, LDAP, ...) theo một cách khác.
• Cho phép Anonymous truy cập bằng Notes hoặc qua trình duyệt là cách "nhanh nhất" để mở một session trên server, nhưng bạn mất kiểm soát người dùng truy cập qua Database ACL và Document ACL bởi vì bạn không thể phân biệt chúng bằng tên.
• Cuối cùng, bạn nên áp dụng tất cả các phương thức bảo mật máy chủ, điều này sẽ làm tăng chi phí, nếu bạn thực hiện không đúng thì cả người dùng hợp lệ sẽ bị khóa.

Chú ý 1: các cơ chế bảo mật khác của Notes bao gồm mã hóa CSDL trên đĩa, bắt buộc đổi mật khẩu, khóa công khai phải khớp lúc đăng nhập, ..
Chú ý 2: Cơ chế bảo mật trong phần này chủ yếu áp dụng cho giao thức Notes. Bảo mật Internet Mail và HTTP Protocol tôi sẽ nói với các bạn trong phần Cấu hình Mail

Các mức bảo mật

Mức	Chức năng
Mức1: General Access	Đây là mức thấp nhất bảo mật dữ liệu Notes, bao gồm các cơ chế bảo mật sau: Bảo mật mức vật lý của máy chủ để ngăn chặn cá nhân mở local file Bảo mật mức mạng ngăn chặn người dùng phá vỡ bảo mật Domino thông qua truy cập trực tiếp file hệ thống Xác thực ( cho phép Anonymous truy cập nếu có thể) Báo cáo truy cập máy chủ Database ACL Các cơ chế bảo mật này là thiết yếu và không bao giờ được bỏ qua
Mức 2: I/O Access	Khi bạn cho tổ chức khác truy cập tới máy chủ của mình, bạn nên thêm vào mức bảo mật lớp 2, bao gồm các cơ chế bảo mật sau: Cổng điều khiển truy cập với danh sách người dùng và nhóm trong file NOTES.INI Mã hóa dữ liệu truyền trên mạng Liên kết tới thư mục với danh sách người dùng và nhóm được phép trong .DIR file
Mức 3: Firewall Dominos	Đây là mức cao được khuyến cáo khi truyền thông và đồng bộ hóa với các tổ chức khác, trực tiếp hoặc qua Internet mà bạn đã tạo firewall giữa vùng mạng bên trong và bên ngoài. Chồng chéo chức năng network firewall: bạn có thể tạo Domino Firewall Domain bằng cách sử dụng Domino Directory và Organization Certifirer

Cơ bản bảo mật mạng

Hạn chế truy cập tới Domino Server qua mạng là một phần nhiệm vụ của người quản trị và có thể thực hiện theo cách sau:

• Yêu cầu mật khẩu người dùng khi đăng nhập vào mạng, thiết lập thời hạn của mật khẩu và không cho phép sử dụng mật khẩu giống nhau, hạn chế khả năng đăng nhập thông qua nhiểu nguồn.Thiết lập thời gian để log out người dùng khi không sử dụng. Notes hỗ trợ đặt User IDs trên SmartCard, khuyến khích người dùng bảo mật tài khoản của họ.
• Nếu Domino server chạy HTTP stack, hãy chạy trên cổng 80 ( 443 nếu dùng SSL)
• Nếu định tuyến mail sử dụng SMTP, dùng cổng 35 ( 465 nếu dùng SSL)
• Nếu hỗ trợ Lotus iNotes, cổng 80 và 443 nên sử dụng ( và cổng 1352 nếu dùng DOLS)
• Phụ thuộc vào các dịch vụ internet khác ( ví dụ LDAP), bạn nên mở các cổng này. Nếu sử dụng Quickr, bạn nên sử dụng cổng 80/443 cho HTTP/HTTPS, 1352 for DOLS, cổng 1533 và 8080 cho online awareness và chat.

Port access list

Bạn có teher hạn chế truy cập tới mạng LAN hoặc cổng COM trên máy chủ bao gồm cả những dòng trong file NOTES.INI hoặc sử dụng câu lệnh >set config :

Allow_Access_<PortName>= <Groupname>, <groupname>
Deny_Acess_<PortName>= <Groupname>, <groupname>

Hãy nhớ những điều sau khi bạn sử dụng Port access

Tên nhóm hoặc tên tổ chức có thể sử ký tự đại diện ví dụ:

Allow_Acess_TCPIP=Admins,LocalDomainServer,*/NN

Dấu * đại diện cho mọi người có tên trong Domino Directory ví dụ

Allow_Access_TCPIP=*

Thiết lập các Port nếu bạn muốn bảo vệ sử dụng tên trong hộp thoại Ports
Thành viên trong nhóm bị cấm truy cập sẽ ghi đè thành viên trong nhóm được phép truy cập
Bạn phải khởi động lại server để Port Access có thể effect
Chú ý: Port access không áp dụng cho Notes Anonymous user hoặc tới browser. Nó chỉ điều khiển những Port nào được xác thực Notes Clients

Mã hóa dữ liệu mạng

Một khía cạnh khác của bảo mật mạng là khả năng giữa Notes Client và Domino Server có thể mã hóa dữ liệu gửi tới Domino Servers

Firewall Network

Bạn nên tạo ra các vùng mạng riêng biệt để tăng cường bảo mật cho hệ thống. Giữa các vùng nên có firewall hoặc router lọc gói tin.

Domino firewall domain

Domino firewall domain được sử dụng để điều khiển truy cập tới internal server. Việc định tuyến mail, đồng bộ hóa với các máy chủ bên ngoài chỉ được thực hiện bởi server trong Domino firewall domain.
Domain này đòi hỏi quản trị phải public một Domino Directory thứ hai có các đặc điểm sau:

• Default ACL mặc định được set là No Access để bên ngoài không thể tìm ra các kết nối khác của bạn
• Chứa tất cả các tài liệu Connections tới tất cả các domain bên ngoài để đồng bộ hóa và định tuyến mail.
• Định nghĩa nhóm server cung cấp truy cập tới server trong Domino Firewall Domain
• Cần thiết thêm vào tài liệu Cross Certificate để xác thực Internal Domino Domain Server với các server bên ngoài.

internal Domino Domain Domino Directory của bạn cần có:

• Tài liệu Connection tới server trong Domino Firewall domain để định tuyến mail và đồng bộ hóa
• Tài liệu Non-Adjacent Domain  để dễ dàng định giải quyết thư tin và cho phép định tuyến mail chỉ từ các Domino Domain xác định.
• Tài liệu Server cho phép truy cập bởi server trong Domino firewall domain
• Tài liệu Cross Certificate, nếu cần thiết để xác thực với server trong Domino firewall organization.

Chú ý:
Domino Directory không được định nghĩa các server trong Domino Domain khác
Trong phần sau tôi sẽ nói về tài liệu Connection, Cross Certificate và No-Adjacent Domain.

Trách nhiệm của người quản trị:

Để đảm bảo thành công trong việc bảo vệ ứng dụng, database developer phải làm việc với Domino Administrator, người mà:

• Đăng ký các tài khoản cần thiết
• Cung cấp cho Notes Client Notes User ID file
• Cung cấp cho người dùng cách tự đăng ký qua web ( tạo tài liệu Person trong Domino Directory có Internet password)
• Nếu chứng thực sử dụng X.509 Internet Certificate, kich hoạt SSL và tạo ra Certificate Authority Key Ring và Certificate, Server Key Ring và Certificate, và phê duyệt người dùng yêu cầu Certificate.

Trách nhiệm của người phát triển:

Như một phần tổng thể của việc thiết kế database, người phát triển phải quyết định:
Ai có thể truy cập tới các mức của mô hình bảo mật, bao gồm những truy cập gán cho người dùng nội bộ và người dùng bên ngoài, quyền được đưa cho Notes clients hoặc browsers.
Dễ dàng điều khiển bảo mật sử dụng groups và roles.
Những mục nào có thể Create và View trên menu cho người dùng xác định
Đọc mức trường ( field-level) và edit access cho Notes Clients.

Bài tiếp theo: Xác thực người dùng và tên ( User authentication and Names).