หลังจากที่ได้กล่าวถึงเรื่องของ Identity ในรูปแบบต่างๆ ไม่ว่าจะเป็น On-premise และ Cloud ไปแล้วในตอนที่ 2 (Identity Management for on-premises and Cloud) ซึงจะเห็นได้ว่าทั้งหมดเป็นการสร้าง Identity ขึ้นใหม่บน Azure Active Directory (AAD) หรือ Azure Active Directory Domain Service (AADDS) เท่านั้น เพียงแต่ว่า Identity ที่สร้างขึ้นใหม่จะมีข้อมูลเหมือนกับ Identity บน On-premise เราเรียกการทำงานในรูปแบบนี้ว่า “Synchronized Identity”
ซึ่ง Synchronized Idenity นี้จะช่วยให้ผู้ใช้งานสะดวกในการจำรหัสผ่านเพียงชุดเดียว แต่ยังคงต้องทำการ Logon บน On-premised และ Office 365 แยกจากกันอยู่ดี จึงเรียกการทำงานในรูปแบนี้ว่า “Same Sign On”
ดังนั้นหากองค์กรที่ต้องการให้มีการทำงานโดยมีการกรอก Credential (ก็คือ username/password) เพียงครั้งเดียว แต่สามารถ Logon ได้ทั้งบน On-premise และบน Cloud นั้น จะต้องใช้การทำงานในรูปแบบ “Single-Sign-On หรือ SSO”
ในตอนนี้จะได้กล่าวถึงการทำงานในการใช้งานแบบ Single-Sign-On ใน Exchange Hybrid configuration ซึ่งจะต้องมีอีกเทคโนโลยีหนึ่งเข้ามาช่วยงาน นั่นก็คือ “Active Directory Federation Service หรือ ADFS” นั่นเองครับ
การทำงานของ Active Directory Federation Service (ADFS)
ก่อนที่จะไปดูการทำงานของ Single-Sign-On นั้น ก่อนอื่นจะขอพาไปทำความรู้จักกับการทำงานของ ADFS เสียก่อน ซึ่งการทำงานของ ADFS นั้นเป็นลักษณะการทำงานที่เรียกว่า “Claim base Authentication” ซึ่งจะขอแนะนำให้รู้จักกับคำศัพท์ที่เกี่ยวข้องเสียก่อน ดังนี้ (ตัวอย่างในรูปที่ 1)
- Claim หมายถึง ข้อมูลบางอย่างที่สามารถใช้ในการระบุถึง Identity ในระบบได้ ตัวอย่างเช่น ชื่อ, Key, Group, หรืออื่นๆ เป็นต้น ซึ่ง Claim จะได้จากผู้ให้บริการ (Claim Provider) ซึ่งในแต่ละ Claim อาจจะมี Claim Type/Value อย่างน้อย 1 หรือมากกว่าก็ได้ ซึ่ง Claim นี้จะถูกบรรจุอยู่ในรูปแบบของ “Security Token” โดย “Security Token Service (STS)”
- Claim Type หมายถึง ชนิดของข้อมูลที่ใช้ประกอบขึ้นเป็น Claim ซึ่ง Claim Type จะต้องมีรูปแบบตามที่กำหนดไว้ใน URI (Uniformed Resource Identifier) ตัวอย่างของ Claim Type เช่น Email, First Name
- Claim Value หมายถึง ค่าของข้อมูลที่ระบุใน Claim Type เช่น [email protected] สำหรับ Claim Type เป็น email, “Example” สำหรับ Claim Type เป็น First name
จากที่กล่าวมาข้างต้นเราจะเห็นได้ว่าใน Claim จะประกอบไปด้วยข้อมูลที่จำเป็นในการทำงาน และสามารถที่จะนำไปใช้ในการทำงานของ Authentication ได้ โดยเราอาจจะอาศัยข้อมูลต่างๆ ที่บรรจุอยู่ใน Security Token เพื่อใช้ในการแสดงตัวตนของผู้ใช้งานได้ เรียกว่า Claim based Authentication ซึ่งจะช่วยให้เกิดความสะดวกในการทำงานมากยิ่งขึ้น โดยเฉพาะอย่างยิ่ง Application ที่เป็นลักษณะ Web Application
ขั้นตอนการทำงานของ ADFS
หลังจากที่ได้กล่าวถึง Claim base Authentication ไปแล้วนั้น ต่อไปจะได้อธิบายถึงการทำงานของ ADFS ในการออก Security Token (ST) ซึ่งภายในนั้นบรรจุ Claim ต่างๆ ของผู้ใช้งานเอาไว้ ซึ่งมีขั้นตอนในการทำงานดังรูปที่ 2
ขั้นตอนที่ 1 – ผู้ใช้งานมีการใช้งานผ่าน User Devices และทำการร้องขอไปยัง Web Application ผ่านทาง URL (Uniform Resources Location) ของ Web Application
ขั้นตอนที่ 2 – Web Application ทำการตรวจสอบพบว่าผู้ใช้งานยังไม่ผ่านกระบวนการ Authentication เนื่องจากตรวจไม่พบ Security Token ในการร้องขอการใช้งาน ดังนั้น Web Application จะทำการ Redirect ผู้ใช้งานไปยัง ADFS เพื่อให้ผู้ใช้ทำการ Logon เสียก่อน
ขั้นตอนที่ 3 – หลังจากที่ผู้ใช้งานได้รับการ Redirect จาก Web Application ก็จะทำการ Logon ที่เครื่อง AD FS
ขั้นตอนที่ 4 – AD FS Server ได้รับข้อมูลการ Logon ของผู้ใช้งาน และทำการเชื่อมต่อไปยัง AD DS (Active Directory Domain Service) เพื่อทำการ Authentication
ขั้นตอนที่ 5 – AD DS ทำการ Authenticate และส่งข้อมูลต่างๆ ที่เกี่ยวข้องให้กับ AD FS
ขั้นตอนที่ 6 – AD FS ทำการสร้าง Security Token ขึ้นจากข้อมูลของ AD DS และ AD FS ทำการส่ง Security Token กลับไปยัง Client Device
ขั้นตอนที่ 7 – ผู้ใช้งานทำการร้องขอไปยัง Web Application อีกครั้งหนึ่ง และทำการส่ง Security Token ที่ได้รับจาก AD FS ไปให้กับ Web Application ด้วย ในครั้งนี้ Web Application จะตรวจสอบว่า Security Token นั้นถูกต้องตรงกับข้อมูลที่ได้กำหนดไว้ก่อนหน้านี้หรือไม่ หากถูกต้อง ผู้ใช้งานก็จะได้รับการอนุญาติให้เข้าถึง Web Application นั้นๆ
ซึ่งหลังจากนี้ Security Token จะต้องถูกส่งไปยัง Web Application ในทุกๆ ครั้งที่มีการร้องขอการใช้งานข้อมูล รวมถึงหากมีการเชื่อมต่อไปยัง Web Application อื่นๆ ก็สามารถนำ Security Token นี้ไปใช้งานต่อได้ในทันที ทำให้เกิดการทำงานที่เป็น Single-Sign-On อย่างแท้จริง
ซึ่งจากรูปดังกล่าวจะเห็นได้ว่าการเชื่อมทั้งหมดนั้นจะต้องมีการเชื่อมต่อจากภายนอกองค์กรผ่าน Firewall เข้ามาซึ่งการที่จะติดตั้ง AD FS Server ไว้ในรูปแบบนี้อาจจะทำให้เกิดความเสี่ยงกับองค์กรได้ ดังนั้นในบางกรณีจึงได้มีการตั้งเครื่อง AD FS Proxy (สำหรับ Windows Server 2012 R2 จะเรียกว่า Web Application Proxy) ขึ้นอีกขั้นหนึ่งดังรูปที่ 3
จากรูปจะเห็นได้ว่ามีการใช้ Firewall เป็น 2 ส่วน ทำให้เกิดส่วนที่เป็น Perimeter Network และส่วนที่เป็น Internal Network ขึ้น โดย AD FS, และ AD DS นั้นจะถูกวางไว้ใน Internal Network ส่วน Web Application และ AD FS Proxy (หรือ Web Application Server) จะอยู่ใน Perimeter Network
ดังนั้นเมื่อเป็นเช่นนี้จึงทำให้เกิดขึ้นตอนเพิ่มขึ้น 2 ขั้นตอนคือ 3.1 และ 6.1 เพิ่มขึ้น และมีการแก้ไขทำงานบางส่วนดังนี้
ขั้นตอนที่ 3 – หลังจากที่ผู้ใช้งานได้รับการ Redirect จาก Web Application ก็จะทำการ Logon ที่เครื่อง AD FS Proxy
ขั้นตอนที่ 3.1 – AD FS Proxy ได้รับการร้องขอจาก device ของผู้ใช้งาน ก็จะตรวจสอบความปลอดภัยชั้นหนึ่งก่อน แล้วจึงส่งต่อไปให้กับ AD FS
ขั้นตอนที่ 6.1 – AD Server ทำการสร้าง Security Token ขึ้น แต่ไม่สามารถส่งไปให้กับ Device ของผู้ใช้งานได้โดยตรง จึงต้องส่งผ่านไปยัง AD FS Proxy เสียก่อน
ขั้นตอนที่ 6 – AD FS Proxy ส่งต่อ Security Token ไปยัง Client Device
จากที่กล่าวถึงการทำงานของ AD FS ไปนั้น จะเห็นได้ว่า การทำงานในรูปแบบนี้ความสำคัญอยู่ที่จะต้องมีความเชื่อถือกัน 2 ส่วนคือ
- ระหว่าง AD FS Proxy กับ AD FS ในส่วนนี้จะเชื่อถือกันผ่านทาง Certificate ที่มีการออกให้ที่ตัว AD FS
- ระหว่าง AD FS กับ Web Application ในส่วนนี้จะต้องมีการทำการกำหนดความสัมพันธ์ระหว่าง AD FS กับ Web Application ขึ้นเสียก่อน เรียกว่า “Relying Party” เพื่อแลกเปลี่ยนข้อมูลที่ถูกต้องในการทำงานระหว่างกันซึ่งจะได้กล่าวถึงในตอนสร้าง Hybrid configuration ในตอนถัดๆ ไป
AD FS กับ Office 365 และ Exchange Hybrid Configuration
จากการที่ AD FS มีประโยชน์ในเรื่องของการทำงานในรูปแบบ Single-Sign-On ดังนั้นจึงถูกเลือกมาใช้ในการเชื่อมต่อระหว่าง On-Primese กับ Office 365 จึงเป็นดังรูปที่ 4
จากรูปที่ 4 จะเห็นได้ว่าการใช้งาน AD FS นั้นยังคงมีความจำเป็นต้องใช้ Tools ในการ Synchronized Active Directory ที่อยู่บน On-premise ขึ้นไปยัง Azure AD เช่นเดิม แต่กระบวนการในการ Authentication เมื่อผู้ใช้งานมีการ Logon เข้าสู่ระบบของ Office 365 จะถูกส่งมาทำการ Authentication ที่ On-premise Active Directory แทน ผ่านทาง AD FS ดังนั้นเราจึงเรียก Identity ที่เก็บไว้ใน Azure AD ในรูปแบบนี้ว่า “Federated Identity”
ดังนั้นจึงไม่มีความจำเป็นที่จะต้อง Shycnonized Password Hash ของผู้ใช้งานขึ้นไปยัง Azure AD ก็ได้
สรุปรูปแบบการ Authentication ใน Office 365
จากที่ได้กล่าวไปทั้งหมดในตอนที่ 2 และ 3 เราสามารถสรุปรูปแบบการ Authentication ใน Office 365 ได้ 3 รูปแบบคือ
รูปแบบที่ 1 : Cloud Only
มีการสร้าง Identity และบริหารจัดการ Identity บน Office 365 ทั้งหมด
รูปแบบที่ 2 : Synchronized Identity
มีการใช้ Azure AD Connect ในการ Synchronized user/password hash ขึ้นไปยัง Azure AD เพื่อทำการ Authentication โดยใช้ username/password เดียวกันระหว่าง On-premise และ Office 365 แต่ยังคงมีการ Authentication แยกกัน
รูปแบบที่ 3 : Federated Identity :
ยังคงต้องมีการใช้งาน Azure AD Connect ในการ Synchronzied user/password (option) ขึ้นไปยัง Azure AD แต่หน้าที่การ Authentication จะอยู่ที่ On-premise ทั้งหมด ผ่านทาง AD FS ซึ่งจะทำให้เกิดการทำงานที่เป็น Single Sign On
เอาละครับ ถึงตอนนี้ก็น่าจะพอมีแนวคิดว่าในองค์กรของเราจะใช้การ Authentication แบบไหนกันแล้วนะครับ ในตอนหน้าผมจะเริ่มพาไปดูการ Configuration กันบ้างแล้วนะครับ เริ่มจาก การติดตั้งและใช้งาน Azure AD Connect แล้วกันครับ
แหล่งข้อมูลอ้างอิง
1. Claims-based identity term definitions https://msdn.microsoft.com/en-us/library/ee534975.aspx
2. Choosing a sign-in model for Office 365https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/
