ปัญหา SSO สตาร์ทอัพ SaaS ส่วนใหญ่ต้องการขายให้กับองค์กร แต่หลายๆ แห่งไม่ได้เตรียมพร้อมสำหรับข้อกำหนดที่องค์กรร้องขอมากที่สุด นั่นคือ การลงชื่อเพียงครั้งเดียว (SSO) ผลิตภัณฑ์ SaaS มักจะออกแบบมาสำหรับชื่อผู้ใช้และรหัสผ่าน ไม่ใช่การผสานรวมที่ซับซ้อนกับผู้ให้บริการข้อมูลประจำตัว (IdP) เช่น Okta, Google หรือ Active Directory 

เมื่อเผชิญกับความท้าทายในการสร้างการผสานรวม นักพัฒนาจำนวนมากจะเตรียมรับมือ อ่านข้อกำหนดการตรวจสอบสิทธิ์และการอนุญาต และเริ่มทำงาน น่าเสียดาย อาจมีช่องว่างมากมายสำหรับการตีความในข้อกำหนดเหล่านี้ ซึ่งการนำ SSO ไปใช้จะกลายเป็นเรื่องยาก ช้า และมีความเสี่ยง หากคุณเป็นบริษัทสตาร์ทอัพขนาดเล็ก หรือแม้แต่ธุรกิจขนาดกลางที่มีทีมวิศวกรที่ยุ่งวุ่นวาย งานนี้อาจเป็นการระบายครั้งใหญ่และทำให้ความสามารถของคุณในการเริ่มหาลูกค้าระดับองค์กรช้าลง

อาจใช้เวลาหลายสัปดาห์ (หรือหลายเดือน) อันมีค่าในการติดตั้ง SSO สำหรับดีลระดับองค์กร และที่สร้างความประหลาดใจให้กับนักพัฒนาหลายๆ คนก็คือ สิ่งที่ได้ผลกับลูกค้าองค์กรรายหนึ่งอาจใช้ไม่ได้กับอีกรายถัดไป SSO เป็นสิ่งที่ท้าทายอย่างไม่คาดคิดที่จะทำอย่างถูกต้องและสม่ำเสมอ เรามาแยกสาเหตุแล้วเสนอแนวทางอื่น

การสร้าง SSO นั้นยากอะไร

ให้ฉันบอกคุณเกี่ยวกับครั้งแรกที่ฉันพยายามใช้ SSO 

ฉันเริ่ม Nylas Mail ในปี 2013 หลังจากเขียนโค้ดบรรทัดแรกในห้องหอพักของฉันที่ MIT กลายเป็นโครงการโอเพ่นซอร์สที่ประสบความสำเร็จอย่างมากและเราระดมเงินได้มากกว่า 10 ล้านเหรียญในความพยายามที่จะโค่น Microsoft Outlook ไม่นานก่อนที่เราจะต้องทำการค้า ซึ่งก็คือตอนที่เราต้องเผชิญหน้ากับผู้ชมกลุ่มใหม่ที่เป็นผู้ซื้อ ซึ่งได้แก่ ผู้นำด้านไอทีและผู้เชี่ยวชาญด้านการจัดซื้อจัดจ้าง เรารู้สึกตื่นเต้นที่จะได้พูดคุยกับลูกค้าระดับองค์กรเกี่ยวกับการนำไปใช้ แต่พวกเขาต้องการคุณสมบัติระดับองค์กรเพื่อเปิดตัว Nylas ในวงกว้าง ในฐานะบริษัทสตาร์ทอัพเล็กๆ เราได้ออกแบบแอปสำหรับผู้ใช้ทั่วไป ไม่ใช่เพื่อให้องค์กรนำไปใช้ เราจึงไม่ได้เตรียมที่จะรวมเข้ากับ IdP หรือตอบสนองข้อกำหนดอื่นๆ ขององค์กร การทำงานเพื่อเพิ่มคุณลักษณะเหล่านั้นได้รับการพิสูจน์แล้วว่ามากเกินไปสำหรับเรา และขัดขวางไม่ให้เราประสบความสำเร็จในตลาดเชิงพาณิชย์ 

บทเรียนในที่นี้คือหากไม่มี SSO และฟีเจอร์สำหรับองค์กรอื่นๆ ผลิตภัณฑ์ก็จะไปได้ไกลเท่านั้น

สิ่งสำคัญที่ต้องทำความเข้าใจเกี่ยวกับ SSO คือปัญหาการรวมระบบ นักพัฒนาส่วนใหญ่สร้างแอปโดยใช้แพ็คเกจ OSS เช่นDeviseซึ่งจัดการการพิสูจน์ตัวตนสำหรับ Ruby on Rails สิ่งนี้ใช้ได้กับลูกค้าที่มีความต้องการพื้นฐาน ช่วยให้ผู้คนสามารถใช้โมเดลต่างๆ ที่มีโมดูลาร์สูงได้ เมื่อถึงจุดหนึ่ง นักพัฒนาจำเป็นต้องผสานรวมผลิตภัณฑ์ของตนเข้ากับ IdP ซึ่งมักจะเริ่มต้นด้วยอะไรก็ตามที่ลูกค้าต้องการมากที่สุด องค์กรต่างๆ ใช้โซลูชัน IdP ที่แตกต่างกัน: บางแห่งอาจใช้โซลูชันที่จำหน่ายทั่วไป เช่น Okta หรือ Azure Active Directory ในขณะที่บางแห่งมีโซลูชันที่ผลิตขึ้นเองเอง ปัญหา SSO

ผู้ขายรายใดก็ตามที่ต้องการขายให้กับบริษัทเหล่านี้จะต้องผสานรวมกับ IdP เหล่านี้ทั้งหมด ซึ่งหมายถึงการจัดการทั้งการตรวจสอบความถูกต้องของ IdP และผู้ใช้ที่ใช้ข้อมูลรับรองดั้งเดิม (นั่นคือ ชื่อผู้ใช้และรหัสผ่านที่มาจากแพลตฟอร์มของผู้ขาย) เนื่องจากไม่มีฟังก์ชัน IdPs ใดที่เหมือนกันและมีผู้ให้บริการ SSO จำนวนมาก คุณจึงต้องรักษาการผสานรวมหลายรายการพร้อมกัน 

หากคุณต้องการอ่านเกี่ยวกับขั้นตอนอื่นในการเพิ่ม SSO ให้กับผลิตภัณฑ์ขององค์กร นี่คือวิธี ที่  Stack Overflow ทำ

การรวม SSO เป็นมากกว่าการสร้างฟีเจอร์และฟังก์ชันการทำงาน ต้องใช้ความพยายามอย่างมากในการปรับขั้นตอนการเข้าสู่ระบบของแอปให้ราบรื่น การจัดระเบียบและการเปิดใช้งานคุณสมบัติขึ้นอยู่กับฟังก์ชันการทำงานของ IdP และต้องการตรรกะทางธุรกิจใหม่ที่มีความเกี่ยวข้องกับมือถือและการตรวจสอบสิทธิ์แบบสองปัจจัย (2FA) SSO มักจะมี 2FA ในตัวด้วย สร้างความซับซ้อนเพิ่มเติมที่ต้องพิจารณาควบคู่ไปกับการผสานรวมระดับระบบอื่นๆ 

SAML มีชัยไปกว่าครึ่ง

มีหลายวิธีในการดำเนินการ SSO หนึ่งในความนิยมมากที่สุดคือผ่านมาตรฐานเปิดแบบ XML ที่เรียกว่า Security Assertion Markup Language (SAML) ข้อกำหนดSAMLมีความยืดหยุ่นและมีตัวเลือกมากมายเพื่อให้ครอบคลุมกรณีต่างๆ ที่เป็นไปได้ ไม่มีผู้ขายสองรายใช้ข้อมูลจำเพาะในลักษณะเดียวกัน กล่าวอีกนัยหนึ่ง มันไม่ได้ใช้งานอย่างสม่ำเสมอ และ SAML มี “รสชาติ” หลายอย่าง เป็นผลให้มีโอกาสมากมายสำหรับปัญหาด้านความปลอดภัย

พูดให้ชัดเจน ไม่ใช่ว่าสเปคได้รับการออกแบบมาไม่ดี เมื่อโปรโตคอลได้รับการออกแบบ นักออกแบบต้องการครอบคลุมความเป็นไปได้มากมาย สามารถทำได้หลายอย่างด้วย SAML ที่ไม่ค่อยได้นำมาใช้ แต่การผสานรวม SSO ยังคงต้องพร้อมรองรับกรณีขอบบางกรณี ซึ่งเป็นจุดที่ช่องโหว่ปรากฏขึ้น

เพย์โหลด SAML

เมื่อเตรียมการรวม SSO ผู้ให้บริการองค์กรมักจะดำเนินการตรวจสอบความปลอดภัยของรหัส SAML เพื่อค้นหารหัสหรือโฟลว์ที่ใช้ประโยชน์ได้ ตัวอย่างเช่น SAML ใช้ใบรับรองและลายเซ็นสำหรับเพย์โหลด ซึ่งโครงสร้างข้อมูลที่ซ้อนกันอาจมีความซับซ้อนเป็นพิเศษ สิ่งนี้มีประโยชน์สำหรับการจัดการการสื่อสาร IdP หลายระดับ โดยเฉพาะอย่างยิ่งในองค์กรขนาดใหญ่ที่อาจมีการตรวจสอบสิทธิ์ SAML หลายชั้นเพื่อส่งผ่าน แต่ละเลเยอร์มีลายเซ็นที่ต้องได้รับการตรวจสอบ ซึ่งเป็นกระบวนการที่เหมือนกับการปอกหัวหอม การผสานรวม SAML แบบทั่วไปอาจใช้งานและตรวจสอบได้ยาก เนื่องจากไม่ได้เป็นลำดับชั้นเสมอไป และคำขอระหว่างระบบอาจไม่ใช่แบบเชิงเส้น

หากไม่ตรวจสอบทุกเลเยอร์อย่างละเอียด ผู้ประสงค์ร้ายอาจใช้เพย์โหลดในทางที่ผิดได้ การหาประโยชน์จาก SAML ทั่วไปคือการแก้ไขการตอบกลับที่ถูกต้องและใส่ลายเซ็นที่ไม่ถูกต้องจากเซสชันที่หมดอายุ เหตุผลที่ใช้งานได้ง่ายๆ ก็คือ นักพัฒนาซอฟต์แวร์ SAML SSO รายหนึ่งเขียนโค้ดที่ตรวจหาลายเซ็นที่ถูกต้อง แต่ไม่ผ่านการตอบกลับทั้งหมด ทุกเลเยอร์ของเพย์โหลด SAML จำเป็นต้องได้รับการตรวจสอบตลอด องค์กรส่วนใหญ่ไม่มีระบบรหัสหลายระดับ ดังนั้นนี่จึงไม่ใช่การใช้ประโยชน์ทั่วไปโดยเฉพาะ แต่โปรโตคอลรองรับเพราะได้รับการออกแบบโดยคำนึงถึงความยืดหยุ่นประเภทนี้

การขาดมาตรฐานสามารถนำไปสู่ความล้มเหลวและความเปราะบางได้ง่าย

เมื่อพูดถึง SSO มีหลายสิ่งที่ต้องทำให้ถูกต้องและมีรายละเอียดเล็กๆ น้อยๆ มากมายที่ต้องพิจารณา คุณสามารถใช้บางอย่างและทำให้ใช้งานได้ แต่ความทนทานจะมาจากการทดสอบกับการใช้งาน และแม้ว่าข้อมูลจำเพาะจะเป็นมาตรฐาน แต่การใช้งานเหล่านั้นกลับไม่เป็นอย่างนั้น

พิจารณาเขียนการรวม SAML สำหรับแพลตฟอร์มใหม่ขององค์กร แพลตฟอร์มอาจใช้Canonical XMLแต่อาจไม่ประกาศเนมสเปซอย่างชัดเจน ซึ่งอาจทำให้การตรวจสอบสิทธิ์ล้มเหลว แม้ว่าทั้งสองฝ่ายในแต่ละด้านของโฟลว์จะเป็นไปตามข้อกำหนด ก็ไม่มีการรับประกันว่าจะทำงานนอกกรอบ เป็นเรื่องที่น่าปวดหัวอย่างยิ่งเมื่อฝ่ายใดฝ่ายหนึ่งทำการเปลี่ยนแปลงแม้เพียงเล็กน้อยในการดำเนินการของตน เนื่องจากอาจนำไปสู่การเข้าสู่ระบบล้มเหลวซึ่งยากต่อการแก้ไขปัญหาเป็นพิเศษ ผู้ใช้อาจโทรหาแผนกไอทีและพูดว่า “ฉันเข้าสู่ระบบไม่ได้” ซึ่งเป็นการเริ่มต้นการไล่ล่าห่านป่าด้วยความพยายามที่จะแก้ไขปัญหาเกี่ยวกับการเปลี่ยนแปลง XML เล็กน้อยในระบบที่พวกเขาไม่ได้ควบคุม

ลักษณะที่ใช้ XML ของ SAML มาพร้อมกับความท้าทายที่เกี่ยวข้องกับ XML การเรียงลำดับวัตถุและการจัดเรียงเอนทิตีที่ซ้อนกัน (นั่นคือแท็ก) อาจทำให้เกิดปัญหาได้ การแมปแอตทริบิวต์ไม่ได้มาตรฐานในทุกแพลตฟอร์ม ตัวระบุสำหรับผู้ใช้บนแพลตฟอร์มไม่ได้มาตรฐาน บางครั้งคุณได้รับ ID บางครั้งอีเมล บางครั้งไม่มีตัวระบุและมีลักษณะทึบแสง เช่น สตริง Active Directory ที่ทำให้เป็นอนุกรม อาจเป็นเรื่องดึงดูดใจที่จะใช้ไลบรารีโอเพนซอร์ส ซึ่งไม่มีอะไรดีไปกว่าของฟรีราคาถูก แต่มีแพ็คเกจโอเพ่นซอร์สไม่มากนักที่จัดการกับ XML ได้ดี ปัญหา SSO

การออกแบบแอปอาจส่งผลต่อฟังก์ชันการทำงานและความปลอดภัยของ SAML

การรวม SSO อาจแตกต่างกันไปตามโครงสร้างของแอปพลิเคชัน ตัวอย่างเช่น ฉันสามารถลงชื่อเข้าใช้ GitHub ด้วยบัญชี Gmail ส่วนตัวของฉัน จากนั้นจึงข้ามเข้าสู่ระบบภายในบริษัทระบบใดระบบหนึ่ง โดยพื้นฐานแล้ว GitHub ทำหน้าที่เป็นปัจจัยการตรวจสอบสิทธิ์ที่สองสำหรับแอปภายในของฉัน ทำให้ฉันข้ามผ่านกลไกการตรวจสอบสิทธิ์หลักสำหรับแอปได้ คุณสามารถมีวิธีตรวจสอบสิทธิ์หลักและวิธีรอง—และขั้นตอนต่างๆ สำหรับการตรวจสอบสิทธิ์อีเมลและรหัสผ่าน—แต่ระบบเหล่านั้นจะทำงานตามที่ออกแบบไว้หรือไม่นั้นขึ้นอยู่กับลักษณะของแอปพลิเคชันเอง

เมื่อคุณสร้างแอปด้วย SAML SSO คุณไม่ต้องกังวลเกี่ยวกับการเปลี่ยนชื่อผู้ใช้หรือรหัสผ่าน เพราะสามารถทำได้นอกแอปพลิเคชันของคุณ อย่างไรก็ตามกระแสต้องสะท้อนความเป็นจริงนั้น ระบบ IdP บางอย่าง เช่น Active Directory ของ Microsoft ซึ่งมีสตริงที่ไม่ซ้ำและไม่ซ้ำกัน ไม่มีที่อยู่อีเมล หากคุณไม่ได้รับที่อยู่อีเมล คุณต้องหาวิธีอื่นในการระบุและรับรองผู้ใช้ วิธีการดังกล่าวอาจใช้ไม่ได้กับโครงสร้างข้อมูลหรือสถาปัตยกรรมโดยรวมของแอปพลิเคชันของคุณ

แอป SaaS ที่พร้อมใช้งานสำหรับองค์กรจำนวนมากเริ่มต้นการเข้าสู่ระบบ SSO โดยขอโดเมนย่อยขององค์กร การค้นหาเบื้องหลังจะนำคุณไปยังแบบฟอร์มเข้าสู่ระบบสำหรับการเข้าสู่ระบบ IdP ของบริษัทนั้นในแอปพลิเคชัน SaaS นั้น ปัญหาคือผู้ประสงค์ร้ายอาจหาช่องโหว่ได้โดยการพิมพ์โดเมนย่อยของบริษัทต่างๆ และรู้ว่าใครใช้ SSO และ SAML หากผู้ประสงค์ร้ายรายนั้นต้องการใช้ช่องโหว่ด้านความปลอดภัยที่เพิ่งค้นพบ เป็นไปได้ว่าการโจมตีจะทำงานในหน้าจอเข้าสู่ระบบ IdP เหล่านี้อย่างน้อยหนึ่งหน้าจอ

การสร้างส่วนต่อประสานผู้ใช้ที่รองรับ SSO นั้นยากและทุกบริษัทต่างทำสิ่งที่แตกต่างออกไป รูปแบบที่พบบ่อยที่สุดคือให้มีช่องชื่อผู้ใช้และรหัสผ่านพร้อมไอคอน IdP ด้านล่างและในข้อความขนาดเล็ก “ลงชื่อเข้าใช้ด้วย SAML/SSO” การเข้าสู่ระบบ iCloud ของ Apple จะไม่แสดงฟิลด์รหัสผ่านทันที เนื่องจากจะตรวจสอบว่าโดเมนของชื่อผู้ใช้ครอบคลุมอยู่ในโฟลว์ SSO หรือไม่ Slack ใช้ CNAME ที่กำหนดเองใน URL เช่น StackOverflow.slack.com และส่งคุณไปยังขั้นตอนการเข้าสู่ระบบที่ถูกต้อง ไม่มีวิธีมาตรฐานในการทำ ซึ่งเป็นเหตุผลว่าทำไมทุกคนจึงทำแตกต่างกัน

การต้อนรับองค์กรและการออกจากพนักงาน

ความยุ่งยากอีกอย่างที่เกี่ยวข้องกับ SSO ที่ใช้ SAML คือการต้อนรับลูกค้าใหม่ สมมติว่าคุณเป็นผู้ให้บริการ SaaS และคุณเพิ่งลงนามในสัญญาขนาดใหญ่ฉบับแรกกับองค์กรขนาดใหญ่ ตอนนี้ได้เวลานำผู้ใช้ระดับองค์กรเข้าสู่ระบบของคุณแล้ว วิศวกรการรวมระบบของคุณจะได้รับการตั้งค่าการรวม SAML โดยทำงานร่วมกับสถาปนิกด้านความปลอดภัยขององค์กร

การตั้งค่าการรวม SAML เกี่ยวข้องกับการแลกเปลี่ยนชุดพารามิเตอร์ข้อมูล เช่น URL การเปลี่ยนเส้นทาง และการแมปฟิลด์ของแอตทริบิวต์ SAML ไม่มีข้อมูลจำเพาะที่ชัดเจนว่าชื่อควรเป็นอย่างไร (เช่น ความละเอียดอ่อนของตัวพิมพ์เล็กและใหญ่) ดังนั้นจึงจำเป็นต้องทำการทดสอบเพื่อให้แน่ใจว่าทั้งสองด้านทำงานได้ นอกจากนี้ยังจำเป็นต้องอัปโหลดใบรับรองซึ่งไม่มีวิธีการที่ชัดเจนในข้อมูลจำเพาะ

การทดสอบการผสานรวม SAML เป็นอุปสรรคใหญ่สำหรับบริษัทต่างๆ และมักจะทำด้วยตนเอง ซึ่งหมายความว่าเครื่องมือสำหรับการตั้งค่าจะได้รับการจัดการด้วยตนเองเช่นกัน โดยพื้นฐานแล้ว บริษัทต่างๆ จะใช้สเปรดชีตหรือแบบฟอร์มอย่างง่ายสำหรับการแลกเปลี่ยนพารามิเตอร์ข้อมูล กระบวนการนี้มีแนวโน้มที่จะแตกหักง่าย จึงมักได้รับการจัดการด้วยบริการส่วนบุคคลที่สวมถุงมือสีขาว การสร้างแผงการดูแลระบบแบบใช้งานได้หลากหลายสำหรับ SAML นั้นมีค่าใช้จ่ายสูงและยาก ดังนั้นบริษัทต่างๆ มักจะดำเนินการด้วยตนเองจนกว่าโครงการจะประหยัดค่าใช้จ่าย

การประสานงาน การกำหนดค่า การนำไปใช้ และการทดสอบ SSO อาจใช้เวลาหลายสัปดาห์หากไม่ใช่การสื่อสารกลับไปกลับมาหลายเดือน เป็นกระบวนการที่ลำบาก มักจะเกี่ยวข้องกับการอภิปรายจำนวนมากและการทำงานเกี่ยวกับการรับรองความถูกต้อง (“นี่คือข้อมูลระบุตัวตนที่ตรวจสอบความถูกต้องของผู้ใช้”) และการอนุญาต (“นี่คือบริการและคุณสมบัติที่ผู้ใช้ที่ผ่านการตรวจสอบแล้วสามารถเข้าถึงได้”) ระบบ Enterprise ID เช่น SAML ทำการตรวจสอบสิทธิ์เพื่อพิสูจน์ว่าใครบางคนคือบุคคลที่พวกเขากล่าวว่าเป็นเท่านั้น โดยปล่อยให้การอนุญาตขึ้นอยู่กับแอปและบริการต่างๆ SAML ควรเป็นนายหน้าในเซสชันจริง เช่น การอนุญาตแบบบิต การพิสูจน์ว่าบุคคลนั้นเป็นใคร เกือบจะเหมือนกับการสแกนป้าย RFID ที่ประตูรักษาความปลอดภัย สิ่งที่เกิดขึ้นหลังจากที่พวกเขาผ่านประตูไปก็เป็นอีกเรื่องหนึ่ง 

ความท้าทายในการจัดการเซสชัน

เมื่อคุณตรวจสอบสิทธิ์ด้วย SAML แสดงว่าคุณกำลังตรวจสอบสิทธิ์ผู้ใช้ แต่หลังจากการตรวจสอบแล้ว คุณจะตรวจสอบไม่ได้ว่าผู้ใช้นั้นยังคงเป็นเซสชันที่ใช้งานอยู่ในปัจจุบัน คุณรู้ว่าคุณมีเซสชันปัจจุบัน ณ เวลาใดเวลาหนึ่งเมื่อคุณตรวจสอบสิทธิ์ แต่เซสชันของคุณจะอยู่ได้นานแค่ไหน หากเวลาสั้นเกินไป เช่น 24 ชั่วโมง อาจเป็นเรื่องที่น่าปวดหัว เพราะต้องมีการเข้าสู่ระบบทุกวันสำหรับผู้ใช้ทุกคน มีวิธีแก้ไขปัญหานี้หากคุณมีสิทธิ์เข้าถึงระบบระบุตัวตนอื่นๆ แต่ประเด็นคือ: การจัดการเซสชันเป็นสิ่งที่ท้าทาย

สำหรับผลิตภัณฑ์ B2C SaaS การออกจากระบบของผู้ใช้มีผลเสียต่อการรักษาและการมีส่วนร่วม ผลิตภัณฑ์ส่วนใหญ่มีคุกกี้สองสัปดาห์เพื่อให้เซสชันใหม่อยู่เสมอ แต่ผู้ดูแลระบบไอทีขององค์กรไม่ต้องการเช่นนั้นเสมอไป ผู้จำหน่าย SaaS โดยเฉพาะที่เพิ่งขายให้กับลูกค้าองค์กรรายแรก อาจต้องคิดใหม่เกี่ยวกับการจัดการเซสชันสำหรับแอปของตน จากนั้นมีข้อพิจารณาเกี่ยวกับวิธีจัดการเซสชันบนอุปกรณ์เคลื่อนที่ 

ผู้ใช้นอกระบบ

เมื่อองค์กรเซ็นสัญญากับผลิตภัณฑ์ของคุณ พวกเขาจะนำผู้ใช้ใหม่เข้ามาจำนวนมาก แต่ไม่ใช่ผู้ใช้ทั้งหมดที่จะอยู่ตลอดอายุของสัญญา จำเป็นต้องออกแบบกระบวนการที่หลากหลายสำหรับการออกจากงานของพนักงานในองค์กร ตัวอย่างเช่น:

• จะเกิดอะไรขึ้นกับข้อมูลของผู้ใช้เมื่อพนักงานลาออก
• ข้อมูลหรือบัญชีของผู้ใช้จะเปลี่ยนเป็นบัญชีผู้ดูแลระบบหรือไม่
• ควรยกเลิกเซสชันทั้งหมดหรือไม่ ถ้าเป็นเช่นนั้น คุณจะรู้ได้เร็วแค่ไหนและอย่างไรว่าพวกเขาจากไป?
• สิ่งของที่ใช้ร่วมกันจะได้รับการจัดการอย่างไร?
• อะไรที่ต้องปิดการใช้งานและอะไรที่ต้องรักษาไว้?

คำถามเหล่านี้เป็นคำถามสำคัญหลายประการที่ควรพิจารณาเมื่อขายให้กับลูกค้าองค์กร ไม่ใช่เรื่องง่ายที่จะตอบคำถาม โดยเฉพาะอย่างยิ่งหากมีการปิดใช้งานผู้ใช้ด้วยวิธีที่ไม่ยืดหยุ่นอยู่แล้ว

เมื่อพนักงานออกจากองค์กรลูกค้า อาจด้วยแง่ที่ไม่ดี มีโอกาสที่พนักงานจะเข้าถึงข้อมูลที่ละเอียดอ่อน การส่งมอบที่สำคัญที่กำลังดำเนินการ หรือเอกสารที่ใช้ร่วมกันซึ่งมีผลกระทบทางการเงินที่มีผลกระทบ หากปราศจากแผนการที่มั่นคงสำหรับการปิดใช้งานผู้ใช้เหล่านั้น ผู้จำหน่าย SaaS สามารถพบว่าตัวเองอยู่ในเส้นทางที่สำคัญสำหรับกระบวนการปิดระบบ HR, IT และความปลอดภัยของข้อมูลของลูกค้าองค์กร หากพนักงานเลือกที่จะก่อวินาศกรรมหรือยุ่งเกี่ยวกับข้อมูลที่พวกเขาไม่ควรเข้าถึงอีกต่อไป นั่นเป็นข่าวร้ายสำหรับผู้ขาย

ข้ามช่องว่างขององค์กร

เมื่อขายให้กับองค์กร ผลิตภัณฑ์ของคุณต้องมีคุณสมบัติสำหรับองค์กร การใช้ SSO ซึ่งเป็นฟีเจอร์ระดับองค์กรที่ได้รับการร้องขอมากที่สุด อาจต้องมีการเปลี่ยนแปลงตั้งแต่สถาปัตยกรรมแอปพลิเคชันและข้อมูลไปจนถึงวิธีที่ทีมพัฒนาดำเนินการและโต้ตอบกับลูกค้ารายใหญ่ แทบไม่มีสิ่งใดในแอป SaaS ที่ไม่ต้องการการพิจารณาใหม่ (หรืออย่างน้อยการตรวจสอบอีกครั้ง) เพื่อรองรับไคลเอ็นต์องค์กรรายแรก

SSO ไม่ใช่แค่การสร้างฟีเจอร์ระดับองค์กร แต่ยังเกี่ยวกับการรักษาชุดโฟลว์ที่ช่วยให้ไคลเอ็นต์ต่างๆ ที่มี IdP ต่างกันใช้แอปได้ การสร้าง SSO ด้วย SAML ต้องใช้การตัดสินใจและตรรกะทางธุรกิจมากมาย ซึ่งไม่ได้เกิดขึ้นเอง นอกจากนี้ แนวทางปฏิบัติที่ดีที่สุดคือเพื่อให้แน่ใจว่ามีพนักงานมากกว่าหนึ่งคนที่เข้าใจการใช้งาน SAML มิฉะนั้น หากผู้พัฒนาออกไปและไม่มีใครรู้โปรโตคอล มันอาจจะยุ่งเหยิงอย่างรวดเร็ว และองค์กรต่างๆ ก็ไม่ต้องการยุ่งกับ SAML

ถึงตอนนี้ SSO เป็นฟีเจอร์ระดับองค์กรที่สำคัญที่สุดในการนำไปใช้ ดังนั้นหากมีงบประมาณเพียงพอสำหรับฟีเจอร์เดียว ก็ควรเป็น SSO เป็นประตูสู่การขายให้กับบริษัทมากมาย ให้ลึกลงไปอีก ผู้ให้บริการควรพิจารณาว่าสิ่งต่อไปนี้จะเป็นประโยชน์เพิ่มเติมต่อการนำ SAML SSO ไปใช้งานหรือไม่:

• การรวมไดเร็กทอรี
• การจัดการวงจรชีวิตผู้ใช้โดยอัตโนมัติ
• การยกเลิกการจัดสรรผู้ใช้
• เข้าสู่ระบบอัตโนมัติสำหรับการปฏิบัติตามการตรวจสอบและการเก็บรักษาทางอิเล็กทรอนิกส์
• การปฏิบัติตาม SOC 2
• จีดีพีอาร์
• HIPAA
• การควบคุมการเข้าถึงตามบทบาทแบบละเอียด (RBAC)
• การจัดการคีย์องค์กร (นำคีย์และการเข้ารหัสมาเอง)

ก่อนที่จะกระโดดไปที่การสร้าง SSO ให้ดูที่WorkOSก่อน SSO เป็นเพียงหนึ่งในคุณสมบัติที่เรานำเสนอด้วยโค้ดเพียงไม่กี่บรรทัดในแอปของคุณ เรารักษาการผสานรวมกับ IdP ที่ได้รับความนิยมสูงสุด มีแผงการดูแลระบบที่ใช้งานง่ายที่องค์กรต่างๆ ชื่นชอบ นำเสนอการซิงโครไนซ์แบบสดกับไดเร็กทอรีผู้ใช้ขององค์กร และทำให้การยืนยันตัวตนแบบหลายปัจจัยเป็นเรื่องง่าย

Face-sso (By K&O) หากท่านสนใจ เครื่องสแกนใบหน้ารุ่นต่างๆ หลากหลายรุ่น หรือ ติดตั้งระบบสแกนใบหน้า สามารถติดต่อสอบถามได้โดยตรง เรามีแอดมินคอยคอบคำถาม 24 ชั้วโมงที่ Line OA เครื่องสแกนใบหน้า สามารถ ขอราคาพิเศษได้ ตามงบประมาณที่เหมาะสม สอบถามได้สบายใจทั้ง เรื่องค่าบริการ ราคา และ งบประมาณ มั่นใจเพราะเป็นราคาที่สุด คุ้มค่าที่สุด

หากท่านมีความสนใจ บทความ หรือ Technology สามารถติดต่อได้ตามเบอร์ที่ให้ไว้ด้านล่างนี้
Tel.086-594-5494
Tel.095-919-6699