ลงชื่อครั้งเดียว สตาร์ทอัพ 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 ในขณะที่บางแห่งมีโซลูชันที่ผลิตขึ้นเองเอง

ผู้ขายรายใดก็ตามที่ต้องการขายให้กับบริษัทเหล่านี้จะต้องผสานรวมกับ 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 ได้ดี 

การออกแบบแอปอาจส่งผลต่อฟังก์ชันการทำงานและความปลอดภัยของ 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

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

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