 |
 |
|
 |
|
How To Fix Error 807
How To Fix Error 807
EXCHANGE 2010 SERVER ROLES
-
Tầm quan trọng của Server Roles:
Khái niệm về một Exchange Server Role không phải thực sự là một khái niệm mới. Microsoft đã chính thức giới thiệt khái niệm Server Role trong Exchange Server 2007, nhưng trong Exchange Server 2003 chúng ta đã có Server Roles như Mailbox Server, Front-end Server, hay Bridgehead Server.
Điểm khác biệt với một Front-end Server ở Exchange Server 2003 là khi bạn cài đặt Exchange Server 2003, cài đặt gói, bao gồm cả cơ sở dữ liệu, giao thức vận chuyển tin nhắn (SMTP), và những chức năng khác của Exchange Server. Một khi tất cả các Software của Exchange Server 2003 được cài đặt, bạn sẽ phải cấu hình những thay đổi, và disable các dịch vụ không cần thiết để làm cho Server cung cấp đủ những dịch vụ mà bạn yêu cầu, tất cả những việc này được định rõ trong Roles.
Các Exchange Administrator cần hiểu rõ vì sao Server Roles rất quan trọng và vì sao nó làm thay đổi cách chúng ta thường dùng để cấu hình Server. Cấu trúc của Exchange Server 2003 khá vững chắc, nhưng quá trình bảo mật và cấu hình của Exchange Server 2003 Bridgehead hay Front-end Server được hiệu khá ngầm định.
Ngày nay, trong suốt quá trình cài đặt Exchange Server, chúng ta được nhắc nhở để chọn Server Roles nào Exchange Server cung cấp. Ví dụ như hình dưới đây sẽ cho ta thấy nếu ta cài đặt Exchange Server 2010, ta sẽ được nhắc nhở Server Roles nào ta cần thiết phải cài.
Có nhiều thuận lợi rõ ràng và quan trọng đối với phương pháp này:
-
Độ phức tạp khi cấu hình Server được giảm bớt.
-
Có thểm các bước để disable các dịch vụ hay khóa các thành phần không cần thiết -> các thành phần không cần thiết sẽ không được cài đặt.
-
Nhờ các thành phần không cần thiết không được cài đặt nên giảm thiểu các hướng tấn công từ bên ngoài khi lợi dụng những thành phần này -> việc bảo mật Server sẽ được cải thiện .
-
Dễ dàng mở rộng các Server.
-
Exchange Server 2010 Server Roles:
Exchange Server 2010 bao gồm 5 Server Roles có vai trò và chức năng riêng biệt:
-
Mailbox Server
-
Client Access Server
-
Hub Transport
-
Unified Messaging
-
Edge Transport
Nếu bạn đã từng làm việc với Exchange Server 2007 có thể bạn sẽ tự hỏi các Active Clusterd Mailbox và các Passive Clusterd Mailbox Server Role ở đâu. Chúng không còn cần thiết nữa: Clustering có thể có được sau khi cài đặt bởi vì các khái niệm về một Clustered Mailbox Server không còn tồn tại như ở các phiên bản trước đó.
-
Mailbox Server:
Mô hình Mailbox Server
– Có chức năng lưu trữ, quản lý mailbox database & public folder database.
– Mailbox server phải được cài đặt trên Member Server.
2. Hub Transport Server:
Mô hình Hub Transport Server
– Nếu trong hệ thống không có Edge Transport Server, Hub Transport server sẽ đảm nhiệm chức năng vận chuyển e-mail giữa hệ thống nội bộ và internet.
– Ngoài ra, Hub Transport server còn đảm nhiệm chức năng vận chuyển e-mail trong hệ thống nội bộ.
– Có chức năng lọc Spam E-mail.
– Hub Transport server phải là thành viên của hệ thống AD domain (Member Server).
3. Client Access Server:
Mô hình Client Access Server
– Có vai trò hỗ trợ các kết nối từ Mail Client, bao gồm MAPI client, Outlook Web App (HTTP/HTTPS), POP3 client, IMAP Client, Outlook Anywhere (RPC over HTTP), Exchange ActiveSyns client.
– Client Access server phải được cài đặt trên Member Server.
4. Unified Messaging Server:
Mô hình Unified Messaging Server
– Có vai trò cung cấp nền tảng để tích hợp các dịch vụ Voice & Fax vào hệ thống E-mail của bạn.
– Hỗ trợ truy cập Voice Messages (thư thoại) & Fax.
5. Edge Transport Server:
Mô hình Edge Transport Server
– Đóng vai trò là 1 SMTP Gateway để vận chuyển e-mail giữa hệ thống nội bộ và internet.
– Có chức năng loc Spam E-mail .
– Để đảm bảo bào mật, chúng ta nên cài đặt Edge Transport trên 1 Server không tham gia AD domain (Stand Alone Server) trong hệ thống DMZ.
III. Mở rộng Server Roles:
Nếu bạn đã xác định rằng bạn không thể lưu trữ tất cả các Exchange Server Role trên một máy chủ vật lý, bạn sẽ cần bắt đầu tách các Role vào các Multiple Windows Servers. Điều này là thông thường vì bạn cần phải mở rộng quy mô để hỗ trợ người dùng tải lớn hơn so với sức chịu đựng của một máy chủ duy nhất.
Chuyển Client Access và Hub Transport Roles vào Mailbox Server
Trong hình trên, Client Access và Hub Transport Role đã được kết hợp vào trong một Single Windows Server. Điều này cung cấp tính sẵn sàng cao hơn cho các chúc năng truy cập và vận chuyển trong khi vẫn sử dụng chỉ hai Addition Windows Server. Tuy nhiên, Additional Hub Transport Server và Client Access sẽ không cung cấp cho bạn Mailbox Server Redundancy, vì thế bạn cần phải sử dụng Database Availability Groups (DAGs) và Multiple Mailbox Server Role.
Cơ Bản về Mail
Cơ Bản về Mail – cập nhật 06/02/2010
1 – Domain
Một số domain Quốc tế từ chối không nhận mail gởi từ domain local, muốn gởi / nhận mail trên Internet phải mua domain Quốc tế.
2 – Domain Quốc tế khác domain local:
Nếu domain quốc tế khác domain local (tinhte.vnl) thì phải dùng email address policy (e2k7) hoặc Receipient Policy (e2k3) để đổi email address trước khi gởi ra, Mdeamon thì khai báo trong phần Primary Domain
3 – Chiều mail gởi ra (outbound):
Gọi tên:
Mail server gởi (sender)
mail Server nhận (Receiver)
Qui trình:
– Sender tuy vần DNS để tìm MX Record (IP) của domain đích
– Sender telnet port 25 của receiver để báo hiệu muốn gởi mail
– Receiver kiểm tra một số điều kiện để quyết định có nhận mail của sender ko?
– Nếu receiver đồng ý thì sender dùng protocol smtp để gởi mail cho receiver
– kết thúc
Từ đó thấy rằng khi mail không gởi được thì phải kiểm tra lại các bước trên
4 – Relay mail:
Vì lý do nào đó, receiver từ chối không nhận mail của sender, sender phải forward mail cần gởi sang một server trung gian để server này gởi giúp, quá trình này gọi là relay mail
Rất nhiều nhà cung cấp dịch vụ mail relay, hỏi google là có đủ hết! dĩ nhiên phải trả phí.
5 – Chiều Mail nhận về (inbound):
Qua mục (3 – Outbound) ta thấy chiều nhận về domain của chúng ta đóng vai trò receiver
Vậy để nhận mail được từ internet cần thỏa:
– Domain Quốc Tế
– Khai báo MX record trỏ về mail server
Thường có 2 dạng: Online và Offline
Online: Mail từ internet gởi thẳng về server của ta
– cài mail server nội bộ,
– publish port 25 của mail server ra firewall,
– NAT port 25 từ adsl về Firewall
(tuỳ theo tình huống thực tế sẽ có những điều chỉnh phù hợp, ví dụ Firewall có IP Public thì không cần công đoạn NAT port ….)
Offline: ta phải thuê server trung gian nào đó đứng ra nhận mail giúp, sau đó ta cấu hình mail server nội bộ kết nối đến server này tải mail về
Mỗi mô hình đều có ưu/khuyết.
Mail online đòi hỏi phải có 1 hạ tầng hoàn chỉnh và ổn định nhưng ta sẽ làm chủ mọi thứ
Mail offline thì ko cần những thứ trên nhưng bù lại bạn ko làm chủ được mail, ví dụ: rò rỉ thông tin, mất mail ….
“Liệu cơm gắp mắm”!
6-Một số lỗi thường gặp khi gởi mail ra, khi bị những lỗi này mail sẽ ko gởi đi được hoặc đi được nhưng lọt vào spam hết
Lỗi thiếu SPF: để tránh tình trạng giả mạo mail … một số receiver kiểm tra xem sender có nằm trong danh sách những server được phép mang tên source domain để gởi mail không bằng cách truy vấn dns của source domain để tìm 1 record TXT đặc biệt, record này sẽ khai báo những IP, Mailserver … được phép gởi mail mang tên của source domain.
ví dụ trong dns của domain nhatnghe.com có 1 record loại txt khai báo như sau:
“v=spf1 a ip4:203.162.4.11 ~all”
có nghĩa chỉ những mail nào được gởi đi từ ip 203.162.4.11 mới đảm bảo là mail của nhatnghe.com
vậy khi hotmail.com nhận được 1 mail của teo@nhatnghe.com, mailserver của hotmail sẽ kiểm tra xem ip đang gởi mail co phải 203.162.4.11 hay ko? nếu ko phải thì ko nhận.
để có 1 khai báo đầy đủ thì click vô đây: http://www.openspf.org/
– Lỗi thiếu PTR: môt số reciver trước khi quyết đinh có nhận mail của sender hay ko sẽ làm động tác truy vấn ngược lại (reversed lookup) xem IP của sender có thuôc domain mà sender đang gởi mail ko? nếu ko thì ko nhận mail.
ví dụ: sender có IP 210.245.3.4 đang gởi mail teo@nhatnghe.com cho hotmail, hotmail sẽ reversed lookup xem 210.245.3.4 có thuộc domain nhatnghe.com hay ko? nếu ko thuộc thì ko nhận.
trong trường hợp này bạn phải yêu cầu nhà cung cấp dịch vụ tạo PTR record trỏ về domain của bạn.
– Lỗi IP động: một số mail server trên thế giới “né” những mail được gởi từ server có IP động, vụ này hay gặp khi doanh nghiệp dùng adsl ip động, mail server nội bộ ko gởi ra ngoài được
– Lỗi blacklist: một số IP đã từng bị “tiền án tiền sự (chuyên gởi spam) thì bà con sẽ từ chối nhận mail.
Tất cả những lỗi này bắt buộc phải phân tích smtp log để có cách giải quyết phù hợp (tuần sau sẽ có bài viết phân tích smtp log). Còn nếu chỉ nói 1 câu chung chung “mail ko gởi được!” thì thua!
7. Phân Tích Log SMTP Exchange 2003
Xem tại đây…
8. Phân Tích Log Exchange 2007
Xem tại Đây…
9. Phân Tích Log Mdeamon
Xem tại Đây…
10. Một số link hay:
http://technet.microsoft.com/en-us/kb/kb00324958.aspx
N – Còn tiếp
Lỗi Exchange 2010
Cannot INstall Client Access Role
I have done that several times. As part of my troubleshooting, I have removed Exchange 2010 and IIS several times.
Remove process involes:
1. Removing Exchange 2010
2. Removing IIS
3. Deleting c:\Program Files\Microsoft\Exchange Server” folder.
4. Reboot
————————
When I reinstall:
1. Import-Module ServerManager
2. Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart
3. Then I proceed with the Exchange 2010 install (where upon it fails at the Client Access Role part).
4. Pull out hair, scream.
LDAP
LDAP viết tắt Lightweight Directory Access Protocol (tiếng Việt có thể gọi là:
giao thức truy cập nhanh các dịch vụ thư mục) là một chuẩn mở rộng cho phương
thức truy cập thư mục, hay là một ngôn ngữ để LDAP server và client sử dụng để
giao tiếp với nhau.
Một cách tổng quát mà nói, LDAP thường phân chia theo O (Organisation –
tổ chức) và các OU (Organisation Unit – phân bộ). Trong các OU có thể có những
OU con và trong các OU có các CN (Common Name), những nhóm giá trị này
thường được gọi là DN (Distinguished Name – tên gọi phân biệt). Mỗi giá trị chứa
trong LDAP thuộc dạng tên:giá trị, thường được gọi là LDAP Attribute (viết tắt là
attr, mỗi attr được nhận diện như một LDAP Object.
Những điểm ở trên hình thành một cái gọi là LDAP schema và có tiêu chuẩn thống
nhất giữa các ứng dụng phát triển LDAP. Đây là lý do LDAP được ưa chuộng cho
công tác lưu trữ và tích hợp với các cơ phận authentication / authorisation vì
chúng có thể được dùng giữa các LDAP system (bất kể công ty sản xuất) miễn sao
các cty sản xuất tuân thủ đúng tiêu chuẩn chung.
LDAP đóng vai trò rất quan trọng trong việc ứng dụng SSO (single sign
on). Điều này có nghĩa là một người đăng nhập vào một hệ thống, người ấy có thể
truy cập đến các servers / services / tài nguyên… cho phép mà không cần phải xác
thực lại. Thử hình dung việc logon mail.yahoo.com, sau đó có thể nhảy đến yahoo
360, yahoo mailing list…. mà không cần phải xác thực tài khoản nữa. Thử hình
dung yahoo sẽ có những dịch vụ khác và mỗi yahoo account chỉ cần chứa ở 1 nơi
và các dịch vụ để dùng chung một LDAP chứa account để xác thực người dùng.
Thử hình dung yahoo có 1000 servers và 1000 /etc/passwd file để bảo trì ).
Ngoài ra, LDAP được tạo ra đặc biệt cho hành động “đọc”. Bởi thế, xác thực
người dùng bằng phương tiện “lookup” LDAP nhanh, hiệu suất, ít tốn tài nguyên,
đơn giản hơn là query 1 user account trên CSDL.
Các tính chất của LDAP:
Đây là một giao thức hướng thông điệp.
Là một giao thức tìm, truy nhập các thông tin dạng thư mục trên server.
Nó là một giao thức Client/Server dùng để truy cập dịch vụ thư mục,
dựa trên dịch vụ thư mục X500.
LDAP chạy trên TCP/IP hoặc những dịch vụ hướng kết nối khác.
Là một mô hình thông tin cho phép xác định cấu trúc và đặc điểm của
thông tin trong thư mục.
Là một không gian tên cho phép xác định cách các thông tin được tham
chiếu và tổ chức
Một mô hình các thao tác cho phép xác định các tham chiếu và phân bố
dữ liệu
Là một giao thức mở rộng, được định nghĩa nhiều phương thức mở rộng
cho việc truy cập và update thông tin trong thư mục.
Là một mô hình thông tin mở rộng.
Vì LDAP tổ chức dữ liệu theo thư mục phân cấp nên có tính mô tả cao,
được tối ưu cho việc tìm kiếm.
LDAP được so sánh với lightweight vì sử dụng gói tin overhead thấp, được xác định chính xác trên lớp TCP (vì X.500 là một giao thức ứng dụng và chứa nhiều thứ hơn như network header được bao quanh các gói tin ở mỗi layer trước khi nó chuyển đi trong mạng). Mặt khác LDAP được coi là lightweight vì đã lược bỏ rất nhiều phương thức ít được dùng của X.500.
Ở đây chúng ta cần tránh hiểu nhầm từ “thư mục” như trên Windows là folder hay directory, đó là thư mục theo nghĩa hẹp để quản lý hệ thống tệp tin. Từ thư mục trong LDAP mang ý nghĩa rộng hơn, nó bao hàm các cấu trúc dữ liệu dạng liệt kê
theo thư mục (hay mục lục) – một “từ khoá” của dân thư viện nhằm ám chỉ cách thức sắp xếp dữ liệu để tiện truy xuất nhất.
OpenLDAP là 1 mô hình quản lý tập trung không thể thiếu đối với admin về open source, nó tương đương với AD bên Windows Server 2003 vì đều dựa trên chuẩn X.500 và X.509 về quản lý mạng trên mô hình logical phân cấp
Xem dung lượng thư mục, file trong Linux
Xem dung lượng thư mục, file trong Linux
Sử dụng lệnh ‘du’ – để xem dung lượng file hoặc thư mục, cụ thể như sau:
– Để xem dung lượng thư mục tuandd trong /home:
$ du /home/tuandd
– Để xem tổng dung lượng thư mục tuandd,
$ cd /home/tuandd
$ du -ch | grep total
– Để xem dung lượng file và folder cụ thể, có kèm theo đơn vị tính
$ du -ah
Một số thuật ngữ Mail
1. MTA ( Mail Transfer Agent ) :
MTA ( Mail Transfer Agent) là thành phần chuyển nhận mail.
Khi các email được gởi đến từ MUA, MTA có nhiệm vụ nhận diện người
gởi và người nhận từ thông tin đóng gói trong phần header của thư và điền
các thông tin cần thiết vào header.
Sau đó MTA chuyển thư cho MDA để chuyển đến hộp thư ngay tại MTA,
hoặc chuyển cho Remote MTA.
Một phần hay cả bức thư có thể phải viết lại tại các MTA trên đường đi.
SMTP là ngôn ngữ của MTAs
Một số phần mềm là MTA : Postfix, Exim, Mdaemon, Exchange Server,
Sendmail, Qmail
2. MDA ( Mail Delivery Agent ) :
MDA (Mail Delivery Agent) là một chương trình được MTA sử dụng để
đẩy thư vào hộp thư của người dùng. Hộp thư của người dùng có thể dùng
định dạng Mailbox hay Maildir.
MDA có khả năng lọc thư, định hướng thư,…
MTA được tích hợp với một MDA hoặc một vài MDA.
Một số MDA là : Maildrop, Promail, Dovecot…
3. MUA ( Mail User Agent ) :
MUA là chương trình quản lý thư đầu cuối cho phép người dùng có thể đọc
viết là lấy thư về từ MTA.
MUA có thể lấy thư từ Mail server về để xử lý thông qua các giao thức
IMAP , POP3…
Chuyển thư cho một MUA khác thông qua MTA.
Cung cấp giao diện cho người dùng tương tác với thư.
Các phần mềm MUA thông dụng: Microsoft Outlook, Netscape, Pine,…
4. SMTP ( Simple Mail Transfer Protocol ) :
SMTP là thủ tục được phát triển ở mức ứng dụng trong mô hình 7 lớp OSI.
SMTP sử dụng cổng 25 của TCP
SMTP không hỗ trợ các thư không phải dạng văn bản.
SMTP hổ trợ thêm 2 thủ tục khác hổ trợ cho việc lấy thư là POP3 và
IMAP4
SMTP đòi hỏi là MUA và MTA đều phải dùng giao thức SMTP
5. POP3 ( Post Office Protocol 3 ) :
POP (Post Office Protocol) là một trong 2 giao thức phổ biến để lấy thư từ
máy chủ (server mail) về MUA .
POP được phát triển năm 1984 và được nâng cấp lên thành POP3 vào năm
1988 (được sử dụng phổ biến hiện nay).
POP3 kết nối trên nền TCP/IP để đến máy chủ thư điện tử (sử dụng cổng
mặc định 110). Người dùng điền username và password. Sau khi xác thực
đầu client sẽ sử dụng các lệnh của POP3 để lấy hoặc xoá thư.
POP3 làm việc với chế độ offline, nghĩa là thư được lấy về MUA sẽ bị xoá
trên server
6. IMAP (Internet Message Access Protocol) :
IMAP là một giao thức để nhận thư từ server.
IMAP được phát triển vào năm 1986 bởi đại học Stanford và nâng cấp lên
IMAP2 vào năm 1987.
IMAP4 là bản phổ biến hiện nay, nó được chuẩn hoá vào năm 1994.
IMAP sử dụng cổng 143 của TCP
IMAP hổ trợ hoạt động ở chế độ online, offline hoặc disconnect
IMAP cho phép người dùng thao tác như : tập hợp các thư từ máy chủ, tìm
kiếm và lấy thư hay chuyển thư từ thư mục này sang thư mục khác hoặc
xoá thư trên máy chủ.
IMAP cho phép lấy thư về MUA mà không xóa trên máy chủ.
Single Sign On Solution
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:
- 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.
- 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
- 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
- Ta thiết đặt master domain, login-service.domain.com.
- Mỗi một domain nằm trong group SSO đều có script login riêng.
- Mọi hệ thống trên mỗi domain đều sử dụng chung Session Database.
- 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.
(nguồn internet)
CAS
Dùng CAS thì khá phức tạp.
Nên tự implement đơn giản thôi:
+ Có 1 nơi lưu trữ session chung.
+ Có 1 webservice thực hiện authenticate.
Nên tự implement đơn giản thôi:
+ Có 1 nơi lưu trữ session chung.
+ Có 1 webservice thực hiện authenticate.
Ví dụ bạn có 2 site A và B.
User X login vào A. Session của user được lưu vào session storage (chung cho cả A và B). Sau đó user X vào site B. Khi đấy ở site B bạn check session của X => xác định X có login hay không.
CAS
Khi user lần đầu login thì CAS sẽ chọc vào CSDL và thẩm định và lưu session.
Nhưng phần còn lại là khi user chuyển sang domain khác thì em chưa hiểu nó sẽ gọi tới CAS ra sao và thẩm định thế nào?
daotuan74 