싱글 사인온

Single sign-on

Single Sign-On(SSO; 싱글사인온)은 사용자가 단일 ID로 관련된 여러 소프트웨어 시스템에 로그인할 수 있는 인증 방식입니다.

진정한 Single Sign-On을 사용하면 사용자는 한 번 로그인하여 인증 팩터를 다시 입력하지 않고도 서비스에 액세스할 수 있습니다.

대부분의 경우 Lightweight Directory Access Protocol(LDAP) 및 (디렉토리) [1][2]서버에 저장된LDAP 데이터베이스를 사용하여 동일한 사인온(디렉토리 서버 인증)과 혼동하지 마십시오.

사이트가 공통 DNS 상위 [3]도메인을 공유하는 경우에만 쿠키를 사용하여 IP 네트워크를 통해 Single Sign-On의 간단한 버전을 구현할 수 있습니다.

알기 쉽게 하기 위해서, 디렉토리 서버 인증(동일 사인 온)과 싱글 사인 온을 구별합니다.디렉토리 서버 인증은 각 애플리케이션에 인증이 필요하지만 디렉토리 서버로부터의 같은 credential을 사용하는 시스템을 가리킵니다.싱글 사인 온은 단일 인증이 액세스를 제공하는 시스템을 가리킵니다.o 인증 토큰을 설정된 애플리케이션에 심리스하게 전달함으로써 여러 애플리케이션을 지원합니다.

반대로 Single Sign-off 또는 Single Log-out(SLO; 싱글 사인오프)은 단일 사인아웃 액션으로 여러 소프트웨어 시스템에 대한 액세스가 종료되는 속성입니다.

다양한 애플리케이션과 리소스가 서로 다른 인증 메커니즘을 지원하므로 Single Sign-On은 초기 인증에 사용되는 자격 증명을 내부적으로 저장하고 다른 메커니즘에 필요한 자격 증명으로 변환해야 합니다.

Open 등 기타 공유 인증 방식ID 및 열기ID Connect는 리소스 사인온 중에 사용자가 선택을 해야 할 수 있는 다른 서비스를 제공합니다.단, 이러한 다른 서비스(사용자 동의 등)가 [4]비활성화되어 있는 경우 싱글 사인온으로 설정할 수 있습니다.Facebook Connect와 같은 연합된 소셜 로그인의 수는 사용자가 새로운 리소스에 처음 등록할 때 동의 선택 사항을 입력해야 하므로, 가장 엄격한 의미에서 싱글 사인온이라고는 할 수 없습니다.

혜택들

Single Sign-On을 사용하면 다음과 같은 이점이 있습니다.

  • 사용자 패스워드는 외부에서 저장 또는 관리되지 않으므로 서드파티 사이트('페더레이션 인증')[5]에 대한 액세스 위험 경감
  • 다양한 사용자 이름과 비밀번호 조합으로 인한 비밀번호 피로 경감
  • 동일한[5] ID에 대한 비밀번호 재입력 시간 단축
  • 패스워드에 관한[6] IT헬프데스크 문의 건수가 적어 IT비용 절감
  • 관리의 심플화.SSO 관련 태스크는 다른 관리 태스크에 사용되는 것과 동일한 도구를 사용하여 일반 유지 관리 작업의 일부로 투명하게 수행됩니다.
  • 관리 제어 향상.모든 네트워크 관리 정보는 단일 저장소에 저장됩니다.즉, 각 사용자의 권한과 권한에 대한 신뢰할 수 있는 단일 목록이 있음을 의미합니다.이것에 의해, 관리자는 유저의 권한을 변경해, 그 결과가 네트워크 전체에 전파되는 것을 알 수 있습니다.
  • 사용자 생산성 향상.사용자는 더 이상 여러 로그온에 시달리지 않으며 네트워크 리소스에 액세스하기 위해 여러 개의 비밀번호를 기억할 필요도 없습니다.또, 패스워드를 잊어버린 경우는, 헬프 데스크의 스탭에게 있어서도 메리트가 있습니다.
  • 네트워크 보안 강화.복수의 패스워드를 삭제하면, 시큐러티 침해의 일반적인 원인(사용자가 패스워드를 적어 두는 것)도 경감됩니다.마지막으로 네트워크 관리 정보가 통합되기 때문에 관리자는 사용자의 계정을 비활성화하면 계정이 완전히 비활성화됨을 확실하게 알 수 있습니다.
  • 이종 네트워크의 통합.서로 다른 네트워크에 접속함으로써 관리 작업을 통합할 수 있어 관리상의 베스트 프랙티스와 기업 보안 정책을 일관되게 적용할 수 있습니다.

SSO는 다른 모든 애플리케이션과 시스템이 인증 목적으로 사용하는 중앙 집중식 인증 서버를 공유하며, 이를 기술과 결합하여 사용자가 여러 번 자격 증명을 입력할 필요가 없도록 합니다.

비판

일부에서는 RSO(Reduced Sign-On)라는 용어를 사용하여 싱글사인온이 기업 내에서 다양한 수준의 안전한 접근에 대한 요구에 대처하는 데 실용적이지 않으며 여러 인증 서버가 [7]필요할 수 있다는 사실을 반영하고 있습니다.

Single Sign-On은 사용자가 처음 인증되면 많은 리소스에 액세스할 수 있기 때문에('성곽 키') 다른 사용자가 자격 정보를 사용할 수 있고 잘못 사용할 경우 부정적인 영향을 증가시킵니다.따라서 싱글 사인온에서는 사용자 credential 보호에 중점을 두어야 하며 스마트카드나 원타임패스워드 [7]토큰 등의 강력한 인증방식과 조합하는 것이 이상적입니다.

Single Sign-On은 인증 시스템을 매우 중요하게 만듭니다.이 시스템의 가용성이 상실되면 SSO로 통합된 모든 시스템에 대한 액세스가 거부될 수 있습니다.SSO를 세션 페일오버 기능으로 구성하여 시스템 [8]운영을 유지할 수 있습니다.단, 시스템 장애의 위험으로 인해 보안 또는 발전소 바닥 시스템과 같이 접근이 항상 보장되어야 하는 시스템에는 싱글 사인온이 바람직하지 않을 수 있습니다.

게다가 Facebook과 같은 소셜 네트워킹 서비스를 이용하는 싱글 사인온 기술을 사용하면 생산성 때문에 소셜 미디어 사이트를 차단하는 도서관, 학교 또는 직장 내에서 서드파티 웹사이트를 사용할 수 없게 될 수 있습니다.제3자 웹사이트가 적극적으로 검열되지 않을 수 있지만 사용자의 소셜 로그인이 [9][10]차단되면 사실상 차단되는 중국이나 '골든 쉴드 프로젝트'처럼 검열 제도가 활발한 국가에서도 어려움을 겪을 수 있다.

보안.

2012년 [11]3월, 한 연구 논문은 소셜 로그인 메커니즘의 보안에 대한 광범위한 연구를 보고했다.저자들은 유명한 ID 제공자와 Open과 같은 신뢰할 수 있는 당사자 웹사이트에서 8가지 심각한 논리 결함을 발견했습니다.ID(Google ID 및 PayPal Access 포함), Facebook, Janrain, Freelancer, FarmVille 및 Sears.com.연구진은 결함 발견을 공표하기 전에 ID 제공자와 의존 당사자 웹사이트에 알렸기 때문에 취약점이 수정되었고 보안 침해는 [12]보고되지 않았다.

2014년 5월에는 Convert Redirect라는 이름의 취약성이 [13]공개되었습니다.처음 보고된 것은 "OAuth 2.0 및 Open 관련 리다이렉트 취약성"입니다.발견자인 싱가포르 [14][15][16]난양공대 수학박사 왕징의 아이디.실제로 거의 모든[weasel words] Single Sign-On 프로토콜이 영향을 받습니다.Convert Redirect는 XSS 또는 Open [17]Redirect의 영향을 받기 쉬운 서드파티 클라이언트를 이용합니다.

2020년 12월, 2020년 미국 연방 정부 데이터 침해 과정에서 공격자가 연합 [18][19]인증 시스템의 결함을 이용한 것으로 밝혀졌다.

싱글 사인온의 동작으로 인해 로그인한 웹 사이트에 SSO 토큰을 취득하기 위한 요구를 송신하고 해당 토큰과 함께 로그아웃한 웹 사이트에 요청을 송신함으로써 HttpOnly cookie 플래그를 사용하여 토큰을 보호할 수 없으므로 로그아웃한 웹 사이트에 XSS 취약성이 있는 경우 공격자가 세션 하이잭을 수행할 수 있습니다.ng. 또 다른 보안 문제는 SSO에 사용되는 세션을 도난당한 경우(SSO 토큰과 달리 Http Only cookie 플래그로 보호할 수 있음) 공격자가 SSO [20]시스템을 사용하는 모든 웹사이트에 액세스할 수 있다는 것입니다.

사생활

원래 Kerberos 및 SAML에서 구현되었던 것처럼 싱글사인온에서는 사용자가 방문한 각 새로운 자원에 개인정보를 공개하는 것에 대한 선택사항이 사용자에게 주어지지 않았습니다.이는 Kerberos가 발명된 MIT나 모든 리소스가 사내 사이트인 대기업과 같은 단일 기업 내에서 충분히 효과가 있었습니다.그러나 Active Directory Federation Services 등의 연합 서비스가 확산됨에 따라 사용자의 개인정보는 사용자로부터 데이터를 수집한 기업의 통제를 받지 않는 제휴 사이트로 전송되었습니다.현재 개인 정보 보호 규제는 GPR과 같은 법률로 강화되고 있기 때문에 Open과 같은 새로운 방법은ID Connect가 매력적으로 변하기 시작했습니다.예를 들어 Kerberos의 원조인 MIT는 Open을 지원하게 되었습니다.[[21]접속]

이메일주소

이론적으로 Single Sign-On은 전자 메일주소 등의 식별정보를 의존 당사자(크레덴셜컨슈머)에게 공개하지 않고 동작할 수 있지만 많은 크레덴셜 프로바이더에서는 사용자가 어떤 정보를 credential 컨슈머에 전달할지를 설정할 수 없습니다.2019년 현재 구글과 페이스북 로그인은 사용자가 자격증 소비자와 이메일 주소를 공유할 필요가 없습니다.iOS13에 도입된 'Sign in with Apple'은 사용자가 새로운 서비스에 가입할 때마다 고유한 중계 이메일 주소를 요구할 수 있어 자격증 [22]소비자의 계정 연계 가능성을 낮출 수 있다.

공통 구성

Kerberos 기반

  • 초기 사인온은 사용자에게 자격 증명을 요구하며 Kerberos Ticket-Granting Ticket(TGT; 티켓 부여 티켓)을 가져옵니다.
  • 전자 메일 클라이언트, Wiki, 리비전 제어 시스템 등 인증을 필요로 하는 추가 소프트웨어 애플리케이션에서는 티켓 부여 티켓을 사용하여 서비스 티켓을 취득하고 메일 서버/Wiki 서버 등에 대한 사용자 ID를 증명합니다.

Windows 환경 - Windows 로그인이 TGT를 가져옵니다.Active Directory 인식 응용 프로그램이 서비스 티켓을 가져오므로 사용자에게 재인증을 요청하지 않습니다.

Unix/Linux 환경 - Kerberos PAM 모듈을 통해 로그인하여 TGT를 가져옵니다.Evolution, Firefox, SVN 등의 Kerberized 클라이언트애플리케이션에서는 서비스티켓이 사용되기 때문에 사용자는 재인증을 요구받지 않습니다.

스마트 카드 기반

초기 사인온으로 스마트카드를 입력하라는 메시지가 나타납니다.다른 소프트웨어 애플리케이션도 자격 증명을 다시 입력하라는 메시지를 표시하지 않고 스마트 카드를 사용합니다.스마트 카드 기반 Single Sign-On은 스마트 카드에 저장된 인증서 또는 암호를 사용할 수 있습니다.

통합 Windows 인증

통합 Windows 인증은 Microsoft 제품과 관련된 용어이며 Microsoft Windows 2000에서 도입된SSPI 기능과 관련하여 이후의 Windows NT 기반 운영 체제에 포함된 SPNEGO, Kerberos 및 NTLMSSP 인증 프로토콜을 나타냅니다.이 용어는 Microsoft Internet Information Services와 Internet Explorer 간의 자동 인증된 연결을 나타낼 때 가장 일반적으로 사용됩니다.크로스 플랫폼 Active Directory 통합 벤더는 통합 Windows 인증 패러다임을 Unix(Mac 포함) 및 Linux 시스템으로 확장했습니다.

보안 어설션 마크업 언어

Security Assertion Markup Language(SAML)는 SAML ID 공급자와 SAML 서비스 공급자 간에 사용자 보안 정보를 교환하기 위한 XML 기반의 방법입니다.SAML 2.0은 W3C XML 암호화 및 서비스 프로바이더 시작 웹 브라우저 싱글사인온 [23]교환을 지원합니다.SAML 기반의 싱글사인온에서는 사용자 에이전트(통상은 웹 브라우저)를 사용하는 사용자를 서브젝트라고 부릅니다.사용자가 SAML 서비스 공급자에 의해 보호되는 웹 리소스를 요청합니다.서비스 공급자는 사용자의 ID를 알기 위해 사용자 에이전트를 통해 SAML ID 공급자에게 인증 요구를 발행합니다.ID 공급자는 사용자 자격 증명을 제공하는 공급자입니다.서비스 공급자는 ID 공급자의 사용자 정보를 신뢰하여 해당 서비스 또는 리소스에 대한 액세스를 제공합니다.

새로운 구성

액세스 인증 정보로서의 모바일 장치

모바일 디바이스를 액세스 credential로 사용하는 새로운 싱글사인온 인증이 개발되었습니다.사용자의 모바일 디바이스를 사용하여 Open을 포함한 인증 방법을 사용하여 빌딩 액세스 제어 시스템 및 컴퓨터 시스템 등의 여러 시스템에 자동으로 로그온할 수 있습니다.ID Connect 및 SAML([24]액세스 서버에 대한 모바일 디바이스 식별에 사용되는 X.509 ITU-T 암호화 증명서와 조합).

모바일 기기는 "알고 있는 것"인 암호나 "자신이 있는 것"인 생체 인식(지문, 망막 스캔, 얼굴 인식 등)과 달리 "자신이 가진 것"입니다.보안 전문가들은 최적의 보호를 위해 이들 3가지 요소 중 적어도2가지 요소(멀티 팩터 인증)를 사용할 것을 권장합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "What's the Difference b/w SSO (Single Sign On) & LDAP?". JumpCloud. 2019-05-14. Retrieved 2020-10-27.
  2. ^ "SSO and LDAP Authentication". Authenticationworld.com. Archived from the original on 2014-05-23. Retrieved 2014-05-23.
  3. ^ "OpenID versus Single-Sign-On Server". alleged.org.uk. 2007-08-13. Retrieved 2014-05-23.
  4. ^ "OpenID Connect Provider - OpenID Connect Single Sign-On (SSO) - OIDC OAuth Authentication". OneLogin.
  5. ^ a b "Single sign-on and federated authentication". kb.iu.edu.
  6. ^ "Benefits of SSO". University of Guelph. Retrieved 2014-05-23.
  7. ^ a b "Single Sign On Authentication". Authenticationworld.com. Archived from the original on 2014-03-15. Retrieved 2013-05-28.
  8. ^ "Sun GlassFish Enterprise Server v2.1.1 High Availability Administration Guide". Oracle.com. Retrieved 2013-05-28.
  9. ^ Laurenson, Lydia (3 May 2014). "The Censorship Effect". TechCrunch. Archived from the original on August 7, 2020. Retrieved 27 February 2015.
  10. ^ Chester, Ken (12 August 2013). "Censorship, external authentication, and other social media lessons from China's Great Firewall". Tech in Asia. Archived from the original on March 26, 2014. Retrieved 9 March 2016.
  11. ^ Wang, Rui; Chen, Shuo; Wang, XiaoFeng (2012). "Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services". 2012 IEEE Symposium on Security and Privacy: 365–379. doi:10.1109/SP.2012.30.
  12. ^ "OpenID: 취약성 보고서, 데이터 혼란" - 미해결ID Foundation, 2012년 3월 14일
  13. ^ "Facebook, Google Users Threatened by New Security Flaw". Tom's Guide. 2 May 2014. Retrieved 11 November 2014.
  14. ^ "Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID". Tetraph. 1 May 2014. Retrieved 10 November 2014.
  15. ^ "Math student detects OAuth, OpenID security vulnerability". Tech Xplore. 3 May 2014. Retrieved 10 November 2014.
  16. ^ "Facebook, Google Users Threatened by New Security Flaw". Yahoo. 2 May 2014. Retrieved 10 November 2014.
  17. ^ "Covert Redirect Flaw in OAuth is Not the Next Heartbleed". Symantec. 3 May 2014. Retrieved 10 November 2014.
  18. ^ "VMware Flaw a Vector in SolarWinds Breach? — Krebs on Security".
  19. ^ Kovacs, Eduard. "Group Behind SolarWinds Hack Bypassed MFA to Access Emails at US Think Tank". Security Week. Security Week. Retrieved 19 December 2020.
  20. ^ "What Is Session Hijacking?". 22 August 2019.
  21. ^ MIT IST. "OpenID Connect Authorization".
  22. ^ Goode, Lauren (2019-06-15). "App Makers Are Mixed on 'Sign In With Apple'". Wired. ISSN 1059-1028. Retrieved 2019-06-15.
  23. ^ Armando, Alessandro; Carbone, Roberto; Compagna, Luca; Cuéllar, Jorge; Pellegrino, Giancarlo; Sorniotti, Alessandro (2013-03-01). "An authentication flaw in browser-based Single Sign-On protocols: Impact and remediations". Computers & Security. 33: 41–58. doi:10.1016/j.cose.2012.08.007.
  24. ^ "MicroStrategy's office of the future includes mobile identity and cybersecurity". Washington Post. 2014-04-14. Retrieved 2014-03-30.

외부 링크