ผมกำลังทำโครงการหนึ่งโครงการที่มีการเขียนบรรยายว่าต้องเป็น Single Sign On ด้วย แต่ทางเดินที่กำลังทำอยู่นี้ถือได้ว่ายังไม่ค่อยจะถูกต้องเสียเท่าไรด้วยเงื่อนไขเวลาและทรัพยากรที่จำกัด ผมคิดว่าคงไม่ผิดถ้าผมจะเขียนสรุปว่าทางที่ควรทำเป็นอย่างไร เผื่อในอนาคตเราจะได้มีโอกาสแก้ไขปรับปรุงทางที่ผิดนี้ให้ถูกได้
Single Sign On ตามคำแปลคือ การเข้าระบบจากที่เดียว (จะตีความว่า Login หนเดียวก็ได้) แล้วระบบที่ผูกโยงกันจะไม่ถามยืนยันผู้ใช้อีกเลย แค่ชื่อฟังก็ดูยิ่งใหญ่แล้ว มีอีกคำที่เกี่ยวข้องคือ Single Sign Out นั่นคือการออกจากระบบจากที่ ๆ เดียว นั่นหมายถึงเมื่อออกจากระบบแล้ว App ตัวอื่นก็ต้องทราบว่าผู้ใช้งานออกจากระบบไปแล้ว บรรดาหน้าจอที่ถูกเปิดค้างไว้ย่อมต้องยุติการบริการกับผู้ใช้คนนั้นทันที ซึ่งตรงนี้อาจจะยังไม่นำมาพิจารณาในตอนนี้
สำหรับ SharePoint ตั้งแต่รุ่น 2010 เป็นต้นไป ได้เพิ่ม Authentication Method เข้าไปอีก 1 รูปแบบคือ Claims based Authentication (ใน 2013 ไม่มี Classic mode Authentication ให้ใช้แล้ว) ซึ่งสามารถทำได้ 3 วิธีคือ Windows Authentication, Form Authentication (กรอก Membership Provider, Role Provider ลงใน web.config ใน 3 ระบบภายใน SharePoint) และแบบสุดท้ายคือ Trusted Identity Provider
การทำ Single Sign On นั้นแปลว่าต้องมีอะไรซักระบบที่ทำหน้าที่เป็นศูนย์กลางการ Sign On ในกรณีนี้ Windows Authentication และ Trusted Identity Provider ดูจะเป็นที่พึ่งให้กับเราได้ อาจจะสงสัยว่า Form Authentication ไม่ใช่อย่างไร นั่นก็เพราะการ Sign in ด้วย Form Authentication นั้น มีเฉพาะ SharePoint เท่านั้นที่ทราบว่าผู้ใช้กำลังเข้าใช้ระบบอยู่ คงเป็นการยากที่ App อื่นจะสามารถตรวจสอบกลับมายัง SharePoint ว่ามีการเข้าสู่ระบบของ User ดังกล่าวบน SharePoint หรือไม่ รวมถึงหากมีการใช้งานหลาย Web Application แม้จะตั้ง Membership อะไรเหมือน ๆ กันมีความเป็นไปได้ที่จะต้อง Sign in ใหม่แน่
สำหรับ Windows Authentication นั้นข้อได้เปรียบคือไม่ต้องไปตั้งค่าอะไรเพิ่มเติมเลย แต่จะมีปัญหาจาก Web Application นั้นต้องให้บริการสู่ Internet ซึ่งจำเป็นต้องไปผูกกับ Forefront ในภายหลัง และก็มีความหมิ่นเหม่เรื่องค่าใช้จ่ายตามจำนวน User ใน Active Directory ด้วย ทางออกที่น่าจะประหยัดค่าใช้จ่ายเรื่องของลิขสิทธิ์มากที่สุดคือการทำ Trusted Identity Provider
Trusted Identity Provider บน SharePoint นั้นเป็นแค่ Object หนึ่งอันที่สร้างให้กับ SharePoint Farm ในนั้นจะประกอบไปด้วย Url ที่ใช้ในการ Login เข้าระบบ Url ที่ใช้ในการ Login ออกจากระบบซึ่งช่างบังเอิญว่าไปล้อกับ Windows Identity Foundation เสียอย่างเหมาะเจาะ
เมื่อตั้งค่าเสร็จ พอผู้ใช้งานจะทำการ Sign In หน้าจอของผู้ใช้จะถูกส่งไปยังหน้าเว็บซึ่งไม่ใช่ระบบ SharePoint แล้ว สังเกตว่าการ Sign In นี้เกิดบนระบบอื่นไม่ใช่ SharePoint จึงต้องมีข้อตกลงบางอย่างระหว่าง SharePoint กับระบบนอกว่าจะมีข้อความอะไรส่งมาแสดงตัว User ให้ทราบว่าใครเป็นใคร (ถ้ายังไม่มี User บนระบบ SharePoint ก็ต้องสร้างขึ้นมาให้ใหม่ด้วย) โดยปกติ App ที่เป็น Windows Identity Foundation Application นั้นจะมีการส่ง Claim ในรูปแบบ SAML ที่ SharePoint ใช้อยู่แล้ว แต่เราจำเป็นต้องสอน SharePoint ให้ทราบว่า Claims ที่ถูกส่งมามีอะไรบ้าง แล้วจะสามารถเอาไปใช้ยืนยันสิทธิ์อะไรของผู้ใช้ได้บ้าง
เมื่อตั้งค่าเสร็จทุกอย่าง ก็สามารถคาดหวังได้ว่า Claim ที่ถูกส่งมาจากระบบนอกจะสามารถถูกนำไปใช้ใน SharePoint ได้ (ตรงนี้มีการเขียนโปรแกรมเข้ามาเกี่ยวด้วยในการจัดการกับ Claim ที่ถูกส่งมา) ส่วนที่ผมยังไม่เคยไปถึงคือเรื่อง User Profile ที่มาจาก Trusted Identity Provider เนื่องจาก SharePoint Central Administration 2010 ยังคงใช้รูปแบบ Classic mode Authentication ทำให้ไม่สามารถรับรู้ถึง User ที่มาจาก Trusted Identity Provider ได้ จำเป็นต้อง Config เพิ่มเติม ซึ่งจะต่างจาก Form Authentication ที่เราถูกบังคับให้แก้ web.config ของ Central Administration และ Web Service ที่เกี่ยวข้องอยู่แล้ว แต่หากสามารถทำได้ไม่ยาก การจัดการกับ User Profile ก็จะไม่แตกต่างจากกรณีของ Form Authentication คือถ้าต้องการ Profile Synchronization กับฐานข้อมูลนอกก็คงต้องทำ Business Data Connectivity อยู่ดี
สรุปคือการทำ Single Sign On ไม่ใช่งานที่จะทำได้ง่าย ๆ แต่เมื่อทราบขั้นตอนที่ถูกต้องแล้วค่อย ๆ ทำไป ระบบก็สามารถสำเร็จได้ครับ