hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
페이스북에 대한 비판 사용자 인터페이스
뉴스 피드는 해당 스토리에 대한 관심도(좋아요 또는 댓글 수 포함)를 기반으로 하는 알고리즘에 따라 인기 있는 콘텐츠에 초점을 맞출 것입니다. 라이브 피드는 많은 사용자 친구들의 모든 최근 스토리를 표시할 것입니다.
재설계는 사용자들로부터 즉각적인 비판을 받았다. 많은 사람들은 너무 많은 정보가 쏟아져 나오는 것을 좋아하지 않았다. 사람들이 자신이 보는 것을 선택할 수 없다는 사실 또한 문제를 더했다.
2009년 11월, 페이스북은 새로운 개인정보 보호정책을 제안하고 2009년 12월에 변경 없이 채택했다. 그들은 이를 새로운 개인정보 설정과 함께 출시했다. 이 새로운 정책은 "친구 목록"을 포함한 특정 정보를 개인정보 설정 없이 "공개적으로 사용 가능"하다고 선언했다. 이전에는 이 정보에 대한 접근을 제한할 수 있었다. 이 변경으로 인해 "친구 목록"을 비공개로 설정했던 사용자들은 통보도 없이 공개해야 했고, 다시 비공개로 설정하는 옵션은 제거되었다. 이는 EFF와 같은 많은 사람들과 개인정보 보호 단체들의 항의를 받았다.
페이스북에 대한 비판 사용자 인터페이스
이 변화는 라이언 테이트(Ryan Tate)에 의해 페이스북의 거대한 배신으로 묘사되었는데, 사용자 프로필 사진과 친구 목록이 사용자의 공개 목록에 표시되도록 강제했으며, 이전에는 이 정보를 명시적으로 숨기도록 선택했던 사용자에게도 마찬가지였다. 또한, 사용자가 접근 제한을 적극적으로 설정하지 않는 한 사진과 개인 정보가 공개되도록 했다. 예를 들어, "가족 및 관계" 정보가 "친구만" 볼 수 있도록 설정되어 있던 사용자는 기본적으로 "모두" (공개적으로 볼 수 있음)로 변경되었다. 즉, 사용자가 관심을 가지는 파트너의 성별, 관계 상태, 가족 관계와 같은 정보가 페이스북 계정이 없는 사람들에게도 볼 수 있게 되었다. 페이스북은 사용자들의 개인정보를 침해하고 사용자들에게 개인정보 보호를 해제하도록 강요한 것에 대해 크게 비난받았다. 변경 사항을 비판하는 그룹으로는 전자 프런티어 재단과 미국 시민 자유 연맹이 있다. 마크 저커버그 CEO는 전환 과정에서 수백 장의 개인 사진과 이벤트 일정이 노출되었다. 페이스북은 이후 친구 목록을 숨기는 옵션을 다시 포함했지만, 이 설정은 더 이상 다른 개인정보 설정과 함께 나열되지 않으며, 이전처럼 친구 중 특정 사람들에게 친구 목록을 숨기는 기능은 더 이상 불가능하다. 언론인 댄 길모어(Dan Gillmor)는 변경 사항으로 인해 페이스북 계정을 삭제하며, "페이스북을 전적으로 신뢰할 수 없다"고 말했다. 슬레이트 빅 머니(Slate's Big Money)의 하이디 무어(Heidi Moore)는 "양심적 거부"로 계정을 일시적으로 비활성화했다. 다른 언론인들도 이 변화에 대해 비슷한 실망감과 분노를 표출했다. 변경 사항을 옹호하며 창립자 마크 저커버그는 "우리는 이것이 이제 사회적 규범이 될 것이라고 결정하고 그대로 추진했다"고 말했다. 캐나다 개인정보 보호 위원회는 변경 후 불만이 제기되자 페이스북의 개인정보 보호 정책에 대한 추가 조사를 시작했다.
페이스북에 대한 비판 사용자 인터페이스
가짜뉴스 유포 혐의와 2016년 미국 대선에 영향을 미치려 했던 러시아와 가까운 단체들의 광고(참조: 2016년 미국 대통령 선거에 대한 러시아의 개입)에 대한 폭로로 얼룩진 2017년의 어려움 이후, 마크 저커버그는 그의 전통적인 1월 게시물에서 다음과 같이 발표했다.
"페이스북을 만드는 방식에 큰 변화를 주고 있습니다. 저희 제품 팀에 주는 목표를 관련 콘텐츠를 찾는 데 집중하는 것에서 더 의미 있는 사회적 상호작용을 돕는 것으로 바꾸고 있습니다."— 마크 저커버그
페이스북 사용자 설문조사에 따라, 이러한 변화에 대한 열망은 뉴스 피드 알고리즘의 재설정을 통해 다음과 같은 형태로 나타날 것이다.
페이스북에 대한 비판 사용자 인터페이스
최근 뉴스 피드 알고리즘 변경 (콘텐츠: 뉴스 피드#역사 참조)은 "의미 있는 콘텐츠 시청량"을 향상시킬 것으로 예상된다. 이를 위해 새로운 알고리즘은 사용자가 친구들과 가장 활발하게 상호작용할 가능성이 있는 게시물을 결정하고, 예를 들어 미디어 회사나 브랜드의 항목 대신 뉴스 피드의 상단에 표시하도록 되어 있다. 이러한 게시물은 "댓글에서 서로 주고받는 토론을 유발하고 공유하고 반응하고 싶은 게시물"이다. 그러나 마크 저커버그도 인정했듯이, 그는 "사람들이 페이스북에서 보내는 시간과 참여도 측정치가 줄어들 것으로 예상하지만, 페이스북에서 보내는 시간이 더 가치 있을 것으로 기대한다"고 말했다. 페이스북 사용자가 뉴스 피드에서 공개 콘텐츠를 적게 볼수록 브랜드가 소비자에게 도달할 수 있는 기회는 줄어든다. 이는 광고주와 퍼블리셔에게는 분명히 큰 손실이다.
페이스북에 대한 비판 사용자 인터페이스
단순히 소셜 네트워크의 또 다른 업데이트처럼 보이는 이 변화는 필리핀, 미얀마, 남수단과 같은 국가들과 볼리비아, 세르비아와 같은 신흥 민주주의 국가들에서 "플랫폼 중립성을 주장하거나 기능하는 뉴스 생태계에 대한 약속을 설정하고 단순히 변덕스럽게 철회하는 것은 윤리적이지 않다"는 심각한 결과 때문에 널리 비판받고 있다.
실제로 이러한 국가들에서 페이스북은 신뢰할 수 있고 객관적인 플랫폼이라는 약속이었고, 시민들이 자국에서 무슨 일이 일어나고 있는지 알 권리를 촉진하는 방식으로 독립 미디어 회사들이 검열에 맞서 싸우도록 도왔다.
페이스북에 대한 비판 사용자 인터페이스
가짜뉴스에 대한 스캔들과 비판을 미디어 회사 이미지를 약화시키는 방식으로 처리하는 회사의 방식은 미얀마나 남수단과 같이 "무료 기본 서비스" 프로그램에 의해 매료된 취약한 정치 환경을 고려할 때 "잠재적으로 치명적"으로 정의된다.
세르비아 언론인 스테반 도이치노비치(Stevan Dojčinović)는 페이스북을 "괴물"이라고 묘사하며, 회사가 "자사의 결정이 가장 취약한 사람들에게 미치는 영향에 대한 냉소적인 무관심"을 보인다고 비난한다.
실제로 페이스북은 세르비아와 같은 일부 국가에서 사용자 뉴스 피드에서 미디어 회사의 뉴스를 철회하는 실험을 했다. 스테반 도이치노비치는 페이스북이 "주류 채널을 우회하고 [그들의] 이야기를 수십만 명의 독자에게 전달"하는 데 어떻게 도움이 되었는지 설명하는 기사를 썼다. 퍼블리셔에 대한 규칙은 유료 게시물에는 적용되지 않아 언론인은 "강력한 사람들을 위한 또 다른 놀이터가 될 것"이라는 소셜 네트워크에 대한 두려움을 제기했다. (예: 페이스북 광고 구매 허용)
이 사기업을 "세계의 파괴자"로 묘사하는 다른 미디어 회사에서도 비판이 나타났다. LittleThings CEO 조 스파이저(Joe Speiser)는 알고리즘 변화가 "LittleThings의 유기적 트래픽의 약 75%를 제거하고 수익 마진에 큰 타격을 주었다"고 말하며, 콘텐츠 공유를 위해 페이스북에 의존하고 있었기 때문에 회사를 폐쇄할 수밖에 없었다고 밝혔다.
페이스북에 대한 비판 망 중립성
2016년 2월, TRAI는 이동통신 사업자의 제한된 서비스에 대한 차등 데이터 요금 책정에 반대하는 판결을 내려 인도에서 제로 레이팅 플랫폼을 효과적으로 종료시켰다. 제로 레이팅은 최종 사용자에게 비용 없이 제한된 수의 웹사이트에 대한 접근을 제공한다. 인도의 망 중립성 지지자들(SaveTheInternet.in)은 페이스북의 프리 베이식스(Free Basics) 프로그램의 부정적인 영향을 지적하고 대중에게 인식을 확산시켰다. 페이스북의 프리 베이식스 프로그램은 릴라이언스 커뮤니케이션과 협력하여 인도에서 프리 베이식스를 출시하는 것이었다. TRAI의 차등 요금 책정 반대 판결은 인도에서 프리 베이식스의 종말을 알렸다.
이전에 페이스북은 4,400만 달러를 광고에 지출했으며, 모든 인도 사용자들에게 통신 규제 기관에 이 프로그램을 지지하는 이메일을 보내달라고 요청했다. TRAI는 나중에 페이스북에 프리 베이식스 지지자들로부터 구체적인 답변을 제공해달라고 요청했다.
페이스북에 대한 비판 잠재적 경쟁사 대우
2018년 12월, 경쟁사에 대한 페이스북의 행동에 대한 세부 정보가 표면화되었다. 영국 국회의원 데이미언 콜린스는 Six4Three와 페이스북 간의 법원 판결에서 나온 파일들을 공개했다. 이 파일들에 따르면, 소셜 미디어 회사 트위터는 2013년에 자사의 앱인 바인(Vine)을 출시했다. 페이스북은 바인의 데이터 접근을 차단했다.
2020년 7월, 페이스북은 다른 기술 대기업인 애플, 아마존 및 구글과 함께 시장에서 잠재적 경쟁자를 억압하기 위한 유해한 권력과 반경쟁 전략을 유지했다는 비난을 받았다. 해당 기업의 CEO들은 2020년 7월 29일 미국 의회 의원들 앞에서 화상 회의에 참석했다.
페이스북에 대한 비판 선거에 대한 영향
페이스북-케임브리지 애널리티카 정보 유출 사건으로 알려진 사건에서, 페이스북 사용자들은 도널드 트럼프의 대통령 선거를 포함한 우익적 명분을 홍보하기 위해 사전 동의 없이 정치적 광고의 표적이 되었다. 미국 선거 외에도 페이스북은 2019년 다큐멘터리 더 그레이트 해크에서 논의된 바와 같이 아르헨티나, 케냐, 말레이시아, 영국, 남아프리카와 같은 지역에서 선거 영향력 캠페인에 연루되어 있다.
페이스북에 대한 비판 캐나다 뉴스 차단
온라인 뉴스법에 대응하여, 메타 플랫폼스는 2023년 8월 초부터 캐나다 사용자의 뉴스 사이트 접근을 차단하기 시작했다. 이는 산불에 대한 캐나다 지역 뉴스에도 확대되었으며, 트뤼도 총리, 지방 정부 관계자, 학자, 연구원, 이재민들로부터 거센 비판을 받았다.
옐로나이프의 캐빈 라디오 소속 올리 윌리엄스(Ollie Williams)는 사용자들이 뉴스 기사의 스크린샷을 게시해야 했으며, 뉴스를 직접 게시하면 링크가 차단된다고 말했다.
메타는 이러한 비판에 대해 캐나다인들이 "우리 기술을 계속 사용하여 커뮤니티와 연결하고 공식 정부 기관, 비상 서비스 및 비정부 기관으로부터 신뢰할 수 있는 정보에 접근할 수 있다"고 밝히며, 페이스북의 안전 확인 기능을 사용할 것을 권장했다.
Doas
doas("dedicated openbsd application subexecutor")는 다른 사용자로 명령을 실행하는 프로그램이다. 시스템 관리자는 지정된 사용자에게 특정 명령을 실행할 권한을 부여하도록 구성할 수 있다. ISC 라이선스에 따라 자유-오픈 소스이며 유닉스 및 유닉스 계열 운영체제에서 사용할 수 있다.
doas는 테드 우낭스트가 OpenBSD용으로 sudo를 더 간단하고 안전하게 대체하기 위해 개발했다. 우낭스트 자신은 기본 sudo 구성에 문제가 있었고, 이것이 doas를 개발하게 된 동기가 되었다. doas는 2015년 10월 OpenBSD 5.8과 함께 출시되어 sudo를 대체했다. 하지만 OpenBSD는 여전히 sudo를 패키지로 제공한다.
Doas 구성
권한 정의는 구성 파일 /etc/doas.conf에 작성되어야 한다. 구성 파일에 사용되는 문법은 패킷 필터 구성 파일에서 영감을 받았다.
user1이 암호 없이 root로 procmap을 실행하도록 허용:
휠 그룹의 구성원이 root로 모든 명령을 실행하도록 허용:
더 간단한 버전 (기본 사용자가 root일 경우에만 작동하며, 설치 후에는 root이다):
휠 그룹의 구성원이 모든 명령(기본적으로 root)을 실행하고 암호를 입력했음을 기억하도록 허용:
Doas 포트 및 가용성
제시 스미스(Jesse Smith)의 doas 포트는 DragonFlyBSD, FreeBSD, 및 NetBSD용으로 패키징되었다. 저자에 따르면, 일루모스와 macOS에서도 작동한다.
리눅스 포트인 OpenDoas는 데비안, 알파인, 아치, CRUX, 페도라, 젠투, GNU Guix, Hyperbola, 만자로, 파라볼라, NixOS, 우분투, 보이드 리눅스용으로 패키징되었다.
Alpine 리눅스 v3.16 릴리스부터 OpenDoas는 sudo의 권장 대체품이 되었으며, sudo는 배포판 내에서 보안 유지 보수 시간이 단축되었다.
엠시소프트
엠시소프트(Emsisoft Ltd., 2003년 설립)는 뉴질랜드에 본사를 둔 바이러스 검사 소프트웨어 유통 회사이다. 이 회사는 랜섬웨어 공격을 복호화하여 데이터를 복원하는 것으로 유명하다.
엠시소프트 역사
엠시소프트는 크리스티안 마이롤이 2003년 오스트리아에서 설립한 안티-멀웨어 및 사이버 보안 소프트웨어 및 컨설팅 회사이다. 이 회사는 기업과 개인이 랜섬웨어 공격으로 암호화된 컴퓨터 파일을 복구하는 데 도움이 되는 안티-멀웨어 소프트웨어 및 복호화 도구를 만든다. 또한 랜섬웨어 공격을 추적하고 연구를 생성한다.
CEO인 마이롤은 2014년 뉴질랜드 시골로 이전했으며, 엠시소프트 본사를 그 나라로 옮겼지만, 유럽, 아시아, 미국 전역의 직원들은 원격 근무를 계속했다.
2019년, 엠시소프트는 유럽 연합 법집행협력청의 노 모어 랜섬 프로젝트에 복호화 도구를 기부했다. 이 회사의 복호화 도구는 2021년 미국, 유럽, 영국 전역의 수십 개 기업을 대상으로 한 카세야 VSA 랜섬웨어 공격,다크사이드 및 블랙매터 랜섬웨어 공격 해결에도 사용되었다.
엠시소프트 역사
아일랜드 국립 사이버 보안 센터는 2021년 5월 엠시소프트의 복호화 도구를 사용하여 아일랜드 보건 서비스 부서가 랜섬웨어 공격에서 복구하는 것을 도왔다.
2021년 초, 엠시소프트는 구성 오류로 인해 시스템 데이터 유출을 겪었으며, 이로 인해 엠시소프트가 생성한 이메일 주소를 포함한 로그 기록이 담긴 데이터베이스가 공개되었고, 최소 한 명의 승인되지 않은 개인이 접근했다. 공격을 감지한 후, 엠시소프트는 손상된 시스템 연결 해제를 포함한 보안 메커니즘을 구현하고 포렌식 분석을 사용하여 사건을 조사했다. 고객에게는 통보되었고 엠시소프트는 이 사건에 대해 공식적으로 사과했다.
엠시소프트 기술
엠시소프트의 안티-멀웨어 기술은 엠시소프트 안티-멀웨어라고 불리며, 안티-멀웨어 홈, 비즈니스 보안, 엔터프라이즈 보안의 세 가지 버전이 있다. 이 회사는 또한 악성 및 피싱 웹사이트에 대한 접근을 차단할 수 있는 웹 브라우저 구글 크롬, 모질라 파이어폭스, 마이크로소프트 엣지용 확장 프로그램을 만든다.
마이크로소프트 포어프론트
마이크로소프트 포어프론트(Microsoft Forefront)는 마이크로소프트가 제공했던 기간 업무용 보안 소프트웨어 제품군이다. 마이크로소프트 포어프론트 제품은 컴퓨터 망, 서버 (예: 마이크로소프트 익스체인지 서버 및 마이크로소프트 셰어포인트 서버) 및 개별 장치를 보호하도록 설계되었다. 2015년 현재, 유일하게 활발히 개발 중인 포어프론트 제품은 포어프론트 아이덴티티 매니저(Forefront Identity Manager)이다.
마이크로소프트 포어프론트 구성 요소
포어프론트에는 다음 제품이 포함된다.
Exchange용 보호: Exchange 메시징 환경을 보호하기 위해 단일 솔루션으로 보안 파트너의 여러 스캐닝 엔진을 통합하여 바이러스, 스파이웨어 및 스팸을 탐지하는 단종된 소프트웨어 제품이다. FPE는 사용자 정의 가능한 구성 설정, 필터링 옵션, 모니터링 기능 및 보고서, Forefront Online Protection for Exchange (FOPE) 제품과의 통합을 포함하는 관리 콘솔을 제공한다. 설치 후, 여러 Exchange 서버에서 FPE를 관리하는 것은 Protection Server Management Console로 수행할 수 있다. 또한, FPE는 시스템 관리 작업을 자동화할 수 있는 명령줄 셸 및 작업 기반 스크립팅 기술인 Windows PowerShell을 사용하여 관리할 수 있다.
마이크로소프트 포어프론트 구성 요소
SharePoint용 보호: Microsoft SharePoint Server 문서 라이브러리를 보호하는 단종된 제품이다. 악성코드, 민감한 정보 또는 정책 위반 콘텐츠가 포함된 문서가 업로드되는 것을 방지하는 규칙을 적용한다. Protection Server Management Console 또는 Windows PowerShell을 사용하여 여러 서버에서 SharePoint Server용 보호를 관리할 수 있다.
마이크로소프트 포어프론트 역사
포어프론트 서버 보호 제품의 전신은 Sybari Software에서 개발한 안티바이러스 제품군인 Antigen이었다. Sybari는 2005년 마이크로소프트에 인수되었고, 마이크로소프트 브랜드로 처음 출시된 제품은 Microsoft Forefront Security for SharePoint (FSSP) 버전 10이라고 불렸다. FSSP 버전 10은 Microsoft Office SharePoint Server 2007 또는 Microsoft Windows SharePoint Services 버전 3을 지원하며, FPSP(최종 제품 버전)는 Microsoft Office SharePoint Server 2010, Microsoft SharePoint Foundation 2010, Microsoft Office SharePoint Server 2007 SP1 또는 Windows SharePoint Services 버전 3 SP1을 지원한다.
SAML 2.0
SAML 2.0((Security Assertion Markup Language 2.0)은 SAML(Security Assertion Markup Language) 표준의 한 버전으로, 보안 도메인 간에 인증 및 권한 부여 식별자를 교환하는 데 사용된다. SAML 2.0은 XML 기반 통신 프로토콜로, ID 공급자라고 하는 SAML 기관과 서비스 공급자라고 하는 SAML 소비자가 교장(일반적으로 최종 사용자)에 대한 정보를 전달하는 보안 토큰을 사용한다. SAML 2.0은 웹 기반의 도메인 간 단일 로그인 (SSO)을 가능하게 하여 사용자에게 여러 인증 토큰을 분배하는 관리 오버헤드를 줄이는 데 도움이 된다.
SAML 2.0은 2005년 3월 OASIS 표준으로 비준되었으며, SAML 1.1을 대체했다. SAML 2.0의 중요한 측면은 공식 문서인 SAMLCore, SAMLBind, SAMLProf, 및 SAMLMeta에 자세히 설명되어 있다.
SAML 2.0
24개 이상의 회사와 기관에서 약 30명의 개인이 SAML 2.0 생성에 참여했다. 특히 리버티 얼라이언스는 ID 연합 프레임워크(ID-FF) 사양을 OASIS에 기증했는데, 이 사양은 SAML 2.0 사양의 기반이 되었다. 따라서 SAML 2.0은 SAML 1.1, 리버티 ID-FF 1.2 보관됨 2021-02-24 - 웨이백 머신, 그리고 시볼레스 1.3의 융합을 나타낸다.
SAML 2.0 SAML 2.0 어설션
어설션은 SAML 기관이 만든 0개 이상의 문장을 제공하는 정보 패키지다. SAML 어설션은 일반적으로 <Subject> 요소로 표현되는 주체에 대해 만들어진다. SAML 2.0 사양은 SAML 기관이 만들 수 있는 세 가지 유형의 어설션 문장을 정의한다. 모든 SAML 정의 문장은 주체와 관련이 있다. 세 가지 유형의 어설션 문장은 다음과 같이 정의된다.
SAML 어설션의 중요한 유형은 웹 브라우저 SSO를 용이하게 하는 소위 "전달자(bearer)" 어설션이다. 다음은 ID 공급자(https://idp.example.org/SAML2)가 서비스 공급자(https://sp.example.com/SAML2)에게 발급한 단기 전달자 어설션의 예시다. 이 어설션에는 서비스 공급자가 액세스 제어 결정을 내리는 데 사용하는 것으로 추정되는 인증 어설션 <saml:AuthnStatement>과 속성 어설션 <saml:AttributeStatement>이 모두 포함되어 있다. 접두사 saml:은 SAML V2.0 어설션 네임스페이스를 나타낸다.
SAML 2.0 SAML 2.0 어설션
위 예시에서 <saml:Assertion> 요소에는 다음 자식 요소가 포함되어 있다.
간단히 말해, 어설션은 다음 정보를 인코딩한다.
어설션("b07b804c-7c29-ea16-7300-4f3d6f7928ac")은 ID 공급자(https://idp.example.org/SAML2)에 의해 주체(3f7b3dcf-1674-4ecd-92c8-1544f346baf8)에 대해 서비스 공급자(https://sp.example.com/SAML2)만을 위해 "2004-12-05T09:22:05Z"에 발행되었다.
특히 인증 문은 다음을 주장한다.
<saml:Subject> 요소에서 식별된 주체는 보호된 채널을 통해 전송된 비밀번호를 사용하여 "2004-12-05T09:22:00Z"에 인증되었다.
마찬가지로 속성 문은 다음을 주장한다.
<saml:Subject> 요소에서 식별된 주체는 이 기관에서 '직원' 및 '멤버' 속성을 가지고 있다.
SAML 2.0 SAML 2.0 프로토콜
다음 프로토콜은 SAMLCore에 지정되어 있다.
이 프로토콜 중 가장 중요한 인증 요청 프로토콜은 아래에 자세히 설명되어 있다.
SAML 1.1 웹 브라우저 SSO 프로필에서는 ID 공급자(IDP)에 의해 시작된다. 즉, 비요청 <samlp:Response> 요소가 ID 공급자에서 서비스 공급자(브라우저를 통해)로 전송된다. (접두사 samlp:는 SAML 프로토콜 네임스페이스를 나타낸다.)
그러나 SAML 2.0에서는 서비스 공급자가 ID 공급자에게 명시적인 인증 요청을 발행하면서 흐름이 시작된다. 결과적으로 인증 요청 프로토콜은 SAML 2.0의 중요한 새로운 기능이다.
주체(또는 주체를 대신하여 작동하는 엔터티)가 인증 문을 포함하는 어설션을 얻으려는 경우 <samlp:AuthnRequest> 요소가 ID 공급자에게 전송된다.
SAML 2.0 SAML 2.0 프로토콜
명시적으로 인증 문을 포함하는 어설션을 요청하는 위의 <samlp:AuthnRequest> 요소는 서비스 공급자(https://sp.example.com/SAML2)에 의해 발행된 후 ID 공급자(브라우저를 통해)에게 제시된 것으로 보인다. ID 공급자는 주체를 인증(필요한 경우)하고 인증 응답을 발행하여 서비스 공급자(다시 브라우저를 통해)에게 다시 전송한다.
SAML 메시지는 값으로 또는 참조로 한 엔터티에서 다른 엔터티로 전송된다. SAML 메시지에 대한 참조를 아티팩트라고 한다. 아티팩트의 수신자는 <samlp:ArtifactResolve> 요청을 아티팩트 발행자에게 직접 전송하여 참조를 해결한다. 그러면 발행자는 아티팩트가 참조하는 실제 메시지로 응답한다.
예를 들어, ID 공급자가 다음 <samlp:ArtifactResolve> 요청을 서비스 공급자에게 직접 전송한다고 가정하자(백 채널을 통해).
이에 응답하여 서비스 공급자는 포함된 아티팩트가 참조하는 SAML 요소를 반환한다. 이 프로토콜은 HTTP 아티팩트 바인딩의 기초를 형성한다.
SAML 2.0 SAML 2.0 바인딩
SAML 2.0이 지원하는 바인딩은 바인딩 사양(SAMLBind)에 설명되어 있다.
웹 브라우저 SSO의 경우 HTTP 리다이렉트 바인딩과 HTTP POST 바인딩이 일반적으로 사용된다. 예를 들어, 서비스 공급자는 HTTP 리다이렉트를 사용하여 요청을 보내고 ID 공급자는 HTTP POST를 사용하여 응답을 전송할 수 있다. 이 예시는 엔터티의 바인딩 선택이 파트너의 바인딩 선택과 독립적임을 보여준다.
SAML 프로토콜 메시지는 HTTP GET 요청의 URL 쿼리 문자열에 직접 전송될 수 있다. 실제 URL 길이에 제한이 있으므로 HTTP 리다이렉트 바인딩은 <samlp:AuthnRequest> 메시지와 같은 짧은 메시지에 적합하다. (SAML 응답과 같이 서명되거나 암호화된 SAML 어설션을 포함하는) 더 긴 메시지는 일반적으로 HTTP POST 바인딩과 같은 다른 바인딩을 통해 전송된다.
SAML 2.0 SAML 2.0 바인딩
HTTP 리다이렉트를 통해 전송되는 SAML 요청 또는 응답은 각각 SAMLRequest 또는 SAMLResponse 쿼리 문자열 매개변수를 갖는다. 메시지가 전송되기 전에 메시지는 압축 해제 (헤더 및 체크섬 없음), base64 인코딩, URL 인코딩 순으로 처리된다. 수신 시에는 원래 메시지를 복구하기 위해 이 프로세스가 역순으로 수행된다.
예를 들어, 위 <samlp:AuthnRequest> 메시지를 인코딩하면 다음이 생성된다.
위 메시지(가독성을 위해 서식 지정됨)는 추가 보안을 위해 서명될 수 있다. 실제로는 SP ID를 포함하는 Issuer 및 NameIDPolicy와 같이 <samlp:AuthnRequest>에 포함된 모든 데이터는 IdP와 SP 간에 미리 합의된다(수동 정보 교환 또는 SAML 메타데이터를 통해). 이 경우 요청 서명은 보안 제약이 아니다. <samlp:AuthnRequest>에 Assertion Consumer Service URL과 같이 IdP가 사전에 알지 못하는 정보가 포함된 경우 보안상의 이유로 요청에 서명하는 것이 권장된다.
SAML 2.0 SAML 2.0 바인딩
다음 예시에서는 서비스 공급자와 ID 공급자 모두 HTTP POST 바인딩을 사용한다. 처음에 서비스 공급자는 사용자 에이전트의 요청에 XHTML 양식이 포함된 문서로 응답한다.
SAMLRequest 매개변수의 값은 브라우저를 통해 ID 공급자에게 전송되는 <samlp:AuthnRequest> 요소의 base64 인코딩이다. ID 공급자의 SSO 서비스는 요청을 검증하고 다른 XHTML 양식이 포함된 문서로 응답한다.
SAMLResponse 매개변수의 값은 마찬가지로 브라우저를 통해 서비스 공급자에게 전송되는 <samlp:Response> 요소의 base64 인코딩이다.
폼 제출을 자동화하려면 다음 자바스크립트 코드를 XHTML 페이지의 아무 곳에나 배치할 수 있다.
물론 이는 페이지의 첫 번째 폼 요소에 위의 SAMLResponse를 포함하는 form 요소(forms[0])가 있다고 가정한다.
SAML 2.0 SAML 2.0 바인딩
HTTP 아티팩트 바인딩은 아티팩트 해결 프로토콜과 SAML SOAP 바인딩(HTTP를 통한)을 사용하여 참조를 통해 SAML 메시지를 해결한다. 다음 구체적인 예시를 살펴보자. 서비스 공급자가 ID 공급자에게 <samlp:AuthnRequest> 메시지를 보내려고 한다고 가정하자. 처음에 서비스 공급자는 HTTP 리다이렉트를 통해 ID 공급자에게 아티팩트를 전송한다.
다음으로 ID 공급자는 백 채널을 통해 <samlp:ArtifactResolve> 요청(이전에 표시된 ArtifactResolveRequest와 같은)을 서비스 공급자에게 직접 보낸다. 마지막으로 서비스 공급자는 참조된 <samlp:AuthnRequest> 메시지를 포함하는 <samlp:ArtifactResponse> 요소를 반환한다.
물론 흐름은 다른 방향으로도 갈 수 있다. 즉, ID 공급자가 아티팩트를 발행할 수도 있으며, 사실 이것이 더 일반적이다. 예를 들어, 이 주제의 뒷부분에 나오는 "이중 아티팩트" 프로필 예시를 참조하자.
일반적으로 SAML 2.0 아티팩트는 다음과 같이 정의된다(SAMLBind).
SAML 2.0 SAML 2.0 바인딩
따라서 SAML 2.0 아티팩트는 세 가지 구성 요소로 구성된다. 2바이트 TypeCode, 2바이트 EndpointIndex, 그리고 RemainingArtifact라고 하는 임의의 바이트 시퀀스다. 이 세 가지 정보는 연결되어 base64 인코딩되어 완전한 아티팩트를 생성한다.
TypeCode는 아티팩트 형식을 고유하게 식별한다. SAML 2.0은 유형 0x0004의 아티팩트 하나만 미리 정의한다. EndpointIndex는 아티팩트 발행자(이전에 언급했듯이 IdP 또는 SP일 수 있음)가 관리하는 특정 아티팩트 해결 엔드포인트에 대한 참조다. 유형 정의에 의해 결정되는 RemainingArtifact는 아티팩트의 "핵심"이다.
유형 0x0004 아티팩트의 형식은 다음과 같이 추가로 정의된다.
따라서 유형 0x0004 아티팩트는 44바이트(인코딩되지 않음) 크기다. SourceId는 임의의 바이트 시퀀스지만, 실제로는 SourceId가 발행자의 entityID의 SHA-1 해시인 경우가 많다. MessageHandle은 아티팩트 발행자가 온디맨드로 생성할 수 있는 SAML 메시지를 참조하는 임의의 바이트 시퀀스다.
예를 들어, 다음 16진수 인코딩된 유형 0x0004 아티팩트를 고려하자.
자세히 보면 아티팩트 앞부분에 TypeCode (0x0004)와 EndpointIndex (0x0000)를 볼 수 있다. 다음 20바이트는 발행자의 entityID(https://idp.example.org/SAML2)의 SHA-1 해시이며, 그 뒤에 20개의 임의 바이트가 온다. 이 44바이트의 base64 인코딩이 위 ArtifactResolveRequest 예시에서 볼 수 있는 내용이다.
SAML 2.0 SAML 2.0 프로필
SAML 2.0은 SAML 1.1과 마찬가지로 여전히 웹 브라우저 SSO가 주요 사용 사례지만, SAML 2.0의 범위는 다음의 광범위한 프로필 목록에서 알 수 있듯이 이전 SAML 버전보다 더 넓다.
지원되는 프로필 수가 상당히 많지만, 각 프로필의 바인딩 측면이 별도의 바인딩 사양(SAMLBind)으로 분리되었으므로 프로필 사양(SAMLProf)은 간소화되었다.
SAML 2.0은 ID 공급자(IdP), 서비스 공급자(SP) 및 HTTP 사용자 에이전트를 사용하는 주체를 포함하는 웹 브라우저 SSO 프로필을 지정한다. 서비스 공급자는 네 가지 바인딩 중에서 선택할 수 있으며, ID 공급자는 세 가지 바인딩 중에서 선택할 수 있어 12가지 가능한 배포 시나리오가 발생한다. 아래에서는 세 가지 배포 시나리오를 설명한다.
이것은 가장 일반적인 시나리오 중 하나다. 서비스 공급자는 HTTP-리다이렉트 바인딩을 사용하여 SAML 요청을 IdP SSO 서비스로 보낸다. ID 공급자는 HTTP-POST 바인딩을 사용하여 SAML 응답을 SP 어설션 소비자 서비스로 반환한다.
메시지 흐름은 서비스 공급자의 보안 리소스 요청으로 시작된다.
1. SP에서 대상 리소스 요청
SAML 2.0 SAML 2.0 프로필
주체(HTTP 사용자 에이전트를 통해)는 서비스 공급자에서 대상 리소스를 요청한다.
서비스 공급자는 대상 리소스를 대신하여 보안 검사를 수행한다. 서비스 공급자에 유효한 보안 컨텍스트가 이미 존재하면 2-7단계를 건너뛴다.
서비스 공급자는 사용될 ID 공급자를 발견하기 위해 사용자에게 질문하거나 미리 구성된 IdP를 사용하는 등 모든 종류의 메커니즘을 사용할 수 있다.
2. IdP SSO 서비스로 리다이렉트
서비스 공급자는 적절한 SAMLRequest(및 RelayState, 있는 경우)를 생성한 다음 표준 HTTP 302 리다이렉트를 사용하여 브라우저를 IdP SSO 서비스로 리다이렉트한다.
RelayState 토큰은 서비스 공급자에서 유지 관리되는 상태 정보에 대한 불투명한 참조다. SAMLRequest 매개변수의 값은 <samlp:AuthnRequest> 요소의 압축 해제, base64 인코딩 및 URL 인코딩된 값이다.
SAMLRequest는 SP 서명 키를 사용하여 서명될 수 있다. 그러나 일반적으로 이는 필요하지 않다.
3. IdP에서 SSO 서비스 요청
사용자 에이전트는 ID 공급자의 SSO 서비스에 GET 요청을 발행한다.
SAML 2.0 SAML 2.0 프로필
여기서 SAMLRequest 및 RelayState 매개변수의 값은 리다이렉트에서 제공된 값과 동일하다. ID 공급자의 SSO 서비스는 <samlp:AuthnRequest> 요소를 처리(URL 디코딩, base64 디코딩, 압축 해제 순서로)하고 보안 검사를 수행한다. 사용자에게 유효한 보안 컨텍스트가 없으면 ID 공급자는 임의의 메커니즘(세부 정보 생략)으로 사용자를 식별한다.
4. XHTML 양식으로 응답
SSO 서비스는 요청을 검증하고 XHTML 양식이 포함된 문서로 응답한다.
RelayState 매개변수 값은 3단계에서 보존되었다. SAMLResponse 매개변수 값은 다음 <samlp:Response> 요소의 base64 인코딩이다.
5. SP에서 어설션 소비자 서비스 요청
사용자 에이전트는 서비스 공급자의 어설션 소비자 서비스에 POST 요청을 발행한다.
여기서 SAMLResponse 및 RelayState 매개변수의 값은 4단계의 XHTML 양식에서 가져온다.
6. 대상 리소스로 리다이렉트
어설션 소비자 서비스는 응답을 처리하고 서비스 공급자에 보안 컨텍스트를 생성한 다음 사용자 에이전트를 대상 리소스로 리다이렉트한다.
SAML 2.0 SAML 2.0 프로필
7. SP에서 대상 리소스 다시 요청
사용자 에이전트는 서비스 공급자에서 대상 리소스를 다시 요청한다.
8. 요청된 리소스로 응답
보안 컨텍스트가 존재하므로 서비스 공급자는 리소스를 사용자 에이전트에 반환한다.
이것은 서비스 공급자(SP)와 ID 공급자(IdP) 모두 HTTP POST 바인딩을 사용하는 SAML 2.0 웹 브라우저 SSO 프로필(SAMLProf)의 비교적 간단한 배포다.
메시지 흐름은 SP의 보안 리소스 요청으로 시작된다.
1. SP에서 대상 리소스 요청
주체(HTTP 사용자 에이전트를 통해)는 서비스 공급자에서 대상 리소스를 요청한다.
서비스 공급자는 대상 리소스를 대신하여 보안 검사를 수행한다. 서비스 공급자에 유효한 보안 컨텍스트가 이미 존재하면 2-7단계를 건너뛴다.
2. XHTML 양식으로 응답
서비스 공급자는 XHTML 양식이 포함된 문서로 응답한다.
RelayState 토큰은 서비스 공급자에서 유지 관리되는 상태 정보에 대한 불투명한 참조다. SAMLRequest 매개변수의 값은 다음 <samlp:AuthnRequest> 요소의 base64 인코딩이다.
SAML 2.0 SAML 2.0 프로필
<samlp:AuthnRequest> 요소가 XHTML 양식에 삽입되기 전에 먼저 base64 인코딩된다.
3. IdP에서 SSO 서비스 요청
사용자 에이전트는 ID 공급자의 SSO 서비스에 POST 요청을 발행한다.
여기서 SAMLRequest 및 RelayState 매개변수의 값은 2단계의 XHTML 양식에서 가져온다. SSO 서비스는 <samlp:AuthnRequest> 요소를 처리(URL 디코딩, base64 디코딩, 압축 해제 순서로)하고 보안 검사를 수행한다. 사용자에게 유효한 보안 컨텍스트가 없으면 ID 공급자는 사용자를 식별한다(세부 정보 생략).
4. XHTML 양식으로 응답
SSO 서비스는 요청을 검증하고 XHTML 양식이 포함된 문서로 응답한다.
RelayState 매개변수 값은 3단계에서 보존되었다. SAMLResponse 매개변수 값은 다음 <samlp:Response> 요소의 base64 인코딩이다.
5. SP에서 어설션 소비자 서비스 요청
사용자 에이전트는 서비스 공급자의 어설션 소비자 서비스에 POST 요청을 발행한다.
여기서 SAMLResponse 및 RelayState 매개변수의 값은 4단계의 XHTML 양식에서 가져온다.
SAML 2.0 SAML 2.0 프로필
6. 대상 리소스로 리다이렉트
어설션 소비자 서비스는 응답을 처리하고 서비스 공급자에 보안 컨텍스트를 생성한 다음 사용자 에이전트를 대상 리소스로 리다이렉트한다.
7. SP에서 대상 리소스 다시 요청
사용자 에이전트는 서비스 공급자에서 대상 리소스를 다시 요청한다.
8. 요청된 리소스로 응답
보안 컨텍스트가 존재하므로 서비스 공급자는 리소스를 사용자 에이전트에 반환한다.
이것은 서비스 공급자(SP)와 ID 공급자(IdP) 모두 HTTP 아티팩트 바인딩을 사용하는 SAML 2.0 웹 브라우저 SSO 프로필(SAMLProf)의 복잡한 배포다. 두 아티팩트 모두 HTTP GET을 통해 해당 엔드포인트로 전달된다.
메시지 흐름은 SP의 보안 리소스 요청으로 시작된다.
1. SP에서 대상 리소스 요청
주체(HTTP 사용자 에이전트를 통해)는 서비스 공급자에서 대상 리소스를 요청한다.
서비스 공급자는 대상 리소스를 대신하여 보안 검사를 수행한다. 서비스 공급자에 유효한 보안 컨텍스트가 이미 존재하면 2-11단계를 건너뛴다.
2. IdP의 단일 로그인(SSO) 서비스로 리다이렉트
SAML 2.0 SAML 2.0 프로필
서비스 공급자는 사용자 에이전트를 ID 공급자의 단일 로그인(SSO) 서비스로 리다이렉트한다. RelayState 매개변수와 SAMLart 매개변수가 리다이렉트 URL에 추가된다.
3. IdP에서 SSO 서비스 요청
사용자 에이전트는 ID 공급자의 SSO 서비스를 요청한다.
여기서 token은 서비스 공급자에서 유지 관리되는 상태 정보에 대한 불투명한 참조이고, artifact_1은 2단계에서 발행된 SAML 아티팩트다.
4. SP에서 아티팩트 해결 서비스 요청
SSO 서비스는 <samlp:ArtifactResolve> 요소를 SAML SOAP 메시지에 바인딩하여 서비스 공급자의 아티팩트 해결 서비스에 전송함으로써 아티팩트의 참조를 해제한다.
여기서 <samlp:Artifact> 요소의 값은 3단계에서 전송된 SAML 아티팩트다.
5. SAML AuthnRequest로 응답
서비스 공급자의 아티팩트 해결 서비스는 <samlp:ArtifactResponse> 요소(<samlp:AuthnRequest> 요소 포함)를 SAML SOAP 메시지에 바인딩하여 ID 공급자의 SSO 서비스에 반환한다.
SAML 2.0 SAML 2.0 프로필
SSO 서비스는 <samlp:AuthnRequest> 요소를 처리하고 보안 검사를 수행한다. 사용자에게 유효한 보안 컨텍스트가 없으면 ID 공급자는 사용자를 식별한다(세부 정보 생략).
6. 어설션 소비자 서비스로 리다이렉트
ID 공급자의 SSO 서비스는 사용자 에이전트를 서비스 공급자의 어설션 소비자 서비스로 리다이렉트한다. 이전 RelayState 매개변수와 새 SAMLart 매개변수가 리다이렉트 URL에 추가된다.
7. SP에서 어설션 소비자 서비스 요청
사용자 에이전트는 서비스 공급자의 어설션 소비자 서비스를 요청한다.
여기서 token은 3단계의 토큰 값이고, artifact_2는 6단계에서 발행된 SAML 아티팩트다.
8. IdP에서 아티팩트 해결 서비스 요청
어설션 소비자 서비스는 <samlp:ArtifactResolve> 요소를 SAML SOAP 메시지에 바인딩하여 ID 공급자의 아티팩트 해결 서비스에 전송함으로써 아티팩트의 참조를 해제한다.
여기서 <samlp:Artifact> 요소의 값은 7단계에서 전송된 SAML 아티팩트다.
9. SAML 어설션으로 응답
SAML 2.0 SAML 2.0 프로필
ID 공급자의 아티팩트 해결 서비스는 <samlp:ArtifactResponse> 요소(<samlp:Response> 요소 포함)를 SAML SOAP 메시지에 바인딩하여 서비스 공급자의 어설션 소비자 서비스에 반환한다.
10. 대상 리소스로 리다이렉트
어설션 소비자 서비스는 응답을 처리하고 서비스 공급자에 보안 컨텍스트를 생성한 다음 사용자 에이전트를 대상 리소스로 리다이렉트한다.
11. SP에서 대상 리소스 다시 요청
사용자 에이전트는 서비스 공급자에서 대상 리소스를 다시 요청한다.
12. 요청된 리소스로 응답
보안 컨텍스트가 존재하므로 서비스 공급자는 리소스를 사용자 에이전트에 반환한다.
SAML 2.0 ID 공급자 발견 프로필은 다음 개념을 소개한다.
SAML 2.0 SAML 2.0 프로필
가상의 공통 도메인 예시로, Example UK (example.co.uk)와 Example Deutschland (example.de)가 가상 조직인 Example Global Alliance (example.com)에 속한다고 가정하자. 이 예시에서 도메인 example.com은 공통 도메인이다. Example UK와 Example Deutschland 모두 이 도메인에 존재한다(각각 uk.example.com 및 de.example.com).
공통 도메인 쿠키는 공통 도메인 범위의 보안 브라우저 쿠키다. 각 브라우저 사용자에게 이 쿠키는 최근 방문한 IdP의 기록 목록을 저장한다. 쿠키의 이름과 값은 IdP 발견 프로필(SAMLProf)에 지정되어 있다.
성공적인 인증 행위 후에 IdP는 공통 도메인 쿠키 쓰기 서비스를 요청한다. 이 서비스는 IdP의 고유 식별자를 공통 도메인 쿠키에 추가한다. SP는 보호된 리소스에 대한 인증되지 않은 요청을 받으면 공통 도메인 쿠키 읽기 서비스를 요청하여 브라우저 사용자의 가장 최근에 사용한 IdP를 발견한다.
어설션 질의/요청 프로필은 다음 SAML 2.0 요소를 사용하여 수많은 유형의 소위 질의를 수용하는 일반적인 프로필이다.
SAML SOAP 바인딩은 종종 질의와 함께 사용된다.
속성 질의는 아마도 가장 중요한 유형의 SAML 질의일 것이다. 종종 주체를 대신하여 요청자가 속성을 ID 공급자에게 질의한다. 아래에서는 주체가 직접 발행한 질의의 예시를 보여준다.
이 경우 Issuer가 Subject임을 주목하자. 이것을 속성 자체 질의(attribute self-query)라고 부르기도 한다. ID 공급자는 <samlp:Response> 요소(표시되지 않음)에 래핑된 다음 어설션을 반환할 수 있다.
이전에 표시된 전달자 어설션과 대조적으로, 이 어설션은 주체가 ID 공급자에 인증하는 데 사용한 X.509 인증서의 수명에 해당하는 더 긴 수명을 갖는다. 또한 어설션이 서명되었으므로 사용자는 이 어설션을 의존 당사자에게 푸시할 수 있으며, 사용자가 해당 개인 키의 소유를 증명할 수 있는 한("홀더-오브-키"라는 이름이 붙은 이유) 의존 당사자는 어설션이 정품임을 확신할 수 있다.
SAML 2.0 SAML 2.0 메타데이터
말 그대로 메타데이터는 SAML이 작동(또는 잘 작동)하게 하는 요소다. 메타데이터의 몇 가지 중요한 용도는 다음과 같다.
서비스 공급자가 브라우저를 통해 ID 공급자에게 <samlp:AuthnRequest> 요소를 전송할 준비를 한다. 서비스 공급자는 ID 공급자가 정품이며 사용자의 비밀번호를 피싱하려는 악의적인 ID 공급자가 아님을 어떻게 아는가? 서비스 공급자는 인증 요청을 발행하기 전에 메타데이터에 있는 신뢰할 수 있는 ID 공급자 목록을 참조한다.
ID 공급자가 브라우저를 통해 서비스 공급자로부터 <samlp:AuthnRequest> 요소를 수신한다. ID 공급자는 서비스 공급자가 정품이며 사용자 개인 개인 식별 정보를 수집하려는 악의적인 서비스 공급자가 아님을 어떻게 아는가? ID 공급자는 인증 응답을 발행하기 전에 메타데이터에 있는 신뢰할 수 있는 서비스 공급자 목록을 참조한다.
SAML 2.0 SAML 2.0 메타데이터
메타데이터는 ID 공급자와 서비스 공급자 간의 안전한 트랜잭션을 보장한다. 메타데이터 이전에는 신뢰 정보가 독점적인 방식으로 구현에 인코딩되었다. 이제 신뢰 정보 공유는 표준 메타데이터를 통해 용이해졌다. SAML 2.0은 엔터티가 신뢰 프로세스를 부트스트랩하는 데 활용할 수 있는 잘 정의되고 상호 운용 가능한 메타데이터 형식을 제공한다.
ID 공급자는 <md:EntityDescriptor> 요소에 자신에 대한 데이터를 게시한다.
이 엔터티 디스크립터에 대한 다음 세부 사항에 주목하자.
정의상 ID 공급자는 SAMLProf에 지정된 SAML 웹 브라우저 SSO 프로필을 지원하는 SSO 서비스를 관리한다. 예를 들어 다음 섹션에 표시된 <md:IDPSSODescriptor> 요소에 설명된 ID 공급자를 참조하자.
ID 공급자의 SSO 서비스는 <md:IDPSSODescriptor> 요소에 설명되어 있다.
이전 메타데이터 요소는 ID 공급자의 SSO 서비스를 설명한다. 이 요소에 대한 다음 세부 사항에 주목하자.
SAML 2.0 SAML 2.0 메타데이터
이 섹션 시작 부분에 언급된 대로, Location 속성 값은 서비스 공급자가 SAML 메시지를 라우팅하는 데 사용되며, 이는 악의적인 ID 공급자가 중간자 공격을 조직할 가능성을 최소화한다.
ID 공급자와 마찬가지로 서비스 공급자도 <md:EntityDescriptor> 요소에 자신에 대한 데이터를 게시한다.
이 엔터티 디스크립터에 대한 다음 세부 사항에 주목하자.
정의상 서비스 공급자는 SAMLProf에 지정된 SAML 웹 브라우저 SSO 프로필을 지원하는 어설션 소비자 서비스를 관리한다. 예를 들어 다음 섹션에 표시된 <md:SPSSODescriptor> 요소에 설명된 서비스 공급자를 참조하자.
어설션 소비자 서비스는 <md:SPSSODescriptor> 요소에 포함되어 있다.
<md:SPSSODescriptor> 메타데이터 요소에 대한 다음 세부 사항에 주목하자.
이 섹션 시작 부분에 언급된 대로, Location 속성 값은 ID 공급자가 SAML 메시지를 라우팅하는 데 사용되며, 이는 악의적인 서비스 공급자가 중간자 공격을 조직할 가능성을 최소화한다.
SAML 2.0 SAML 2.0 메타데이터
이전 예시에서는 각 <md:EntityDescriptor> 요소가 디지털 서명된 것으로 표시된다. 그러나 실제로는 여러 <md:EntityDescriptor> 요소가 전체 집합에 대한 단일 디지털 서명과 함께 <md:EntitiesDescriptor> 요소 아래에 그룹화된다.
위 <md:EntitiesDescriptor> 요소에 대한 다음 세부 사항에 주목하자.
일반적으로 메타데이터 집계는 집계 내의 모든 메타데이터의 무결성을 보증하는 페더레이션이라고 하는 신뢰할 수 있는 제3자에 의해 게시된다. 메타데이터 집계는 매우 클 수 있으며, 집계당 수백 또는 수천 개의 엔터티로 구성될 수 있다는 점에 주목하자.
SAML 2.0 각주
주요 참고 자료:
보조 참고 자료:
사용 중단된 참고 자료:
소프트웨어 토큰
소프트웨어 토큰(software token) 또는 소프트 토큰(soft token)은 컴퓨터 서비스 사용을 승인하는 데 사용될 수 있는 다요소 인증 보안 장치의 일부이다. 소프트웨어 토큰은 데스크톱 컴퓨터, 랩톱, 개인 정보 단말기 또는 휴대 전화와 같은 범용 전자 장치에 저장되며 복제될 수 있다. (자격 증명이 전용 하드웨어 장치에 저장되어 물리적 장치 침해 없이 복제될 수 없는 하드웨어 토큰과 대조된다.)
소프트웨어 토큰은 물리적으로 소유하지 않는 것이기 때문에, 기본 암호화 자료의 복제를 기반으로 하는 고유한 위협, 예를 들어 컴퓨터 바이러스 및 소프트웨어 공격에 노출된다. 하드웨어 토큰과 소프트웨어 토큰 모두 봇 기반 중간자 공격 또는 토큰이 제공하는 일회용 비밀번호를 요청하여 제때에 실제 웹사이트에 제공하는 단순한 피싱 공격에 취약하다. 소프트웨어 토큰에는 이점이 있다. 들고 다닐 물리적 토큰이 없고, 배터리가 소모되지 않으며, 하드웨어 토큰보다 저렴하다.
소프트웨어 토큰 보안 아키텍처
소프트웨어 토큰에는 공유 비밀과 공개 키 암호 방식의 두 가지 주요 아키텍처가 있다.
공유 비밀의 경우, 네트워크 관리자는 일반적으로 각 최종 사용자를 위한 구성 파일을 생성한다. 이 파일에는 사용자 이름, 개인 식별 번호 및 비밀이 포함된다. 이 구성 파일은 사용자에게 제공된다.
공유 비밀 아키텍처는 여러 영역에서 잠재적으로 취약하다. 구성 파일이 도난당하고 토큰이 복사되면 손상될 수 있다. 시간 기반 소프트웨어 토큰의 경우, 개인의 개인 정보 단말기나 랩톱을 빌려 시계를 앞당겨 미래에 유효한 코드를 생성하는 것이 가능하다. 공유 비밀을 사용하고 개인 식별 번호와 공유 비밀을 소프트웨어 클라이언트에 함께 저장하는 모든 소프트웨어 토큰은 도난당하여 오프라인 공격에 노출될 수 있다. 공유 비밀 토큰은 각 토큰이 본질적으로 다른 소프트웨어 조각이므로 배포하기 어려울 수 있다. 각 사용자는 비밀의 사본을 받아야 하므로 시간 제약이 발생할 수 있다.
소프트웨어 토큰 보안 아키텍처
일부 최신 소프트웨어 토큰은 공개 키 암호 방식 또는 비대칭 암호 방식에 의존한다. 이 소프트웨어 구조는 소프트웨어 토큰의 전통적인 약점 중 일부를 제거하지만, 주된 약점(복제 가능성)에는 영향을 미치지 않는다. 개인 식별 번호는 토큰 클라이언트 대신 원격 서버에 저장될 수 있으므로 개인 식별 번호를 알지 못하면 도난당한 소프트웨어 토큰은 쓸모가 없게 된다. 그러나 바이러스 감염의 경우, 암호화 자료가 복제될 수 있으며, 사용자가 다음에 인증할 때 개인 식별 번호가 (키 로깅 또는 이와 유사한 방법을 통해) 캡처될 수 있다. 개인 식별 번호를 추측하려는 시도가 있으면 인증 서버에서 감지 및 기록할 수 있으며, 이는 토큰을 비활성화할 수 있다. 비대칭 암호 방식을 사용하면 토큰 클라이언트가 자체 키 쌍을 생성하고 서버와 공개 키를 교환할 수 있으므로 구현도 단순해진다.
트렌드 마이크로 인터넷 시큐리티
트렌드 마이크로 인터넷 시큐리티(Trend Micro Internet Security, 오스트레일리아 이름: PC-cillin 인터넷 시큐리티, 일본 이름: 바이러스 버스터)는 트렌드 마이크로가 일반 사용자 시장을 위해 개발한 바이러스 검사 및 온라인 보안 프로그램이다. 2014년 NSS Lab의 이 시장 소프트웨어 제품 비교 분석에 따르면, 트렌드 마이크로 인터넷 시큐리티는 새로운 인터넷 위협에 가장 빠르게 대응했다. 그러나 2024년 6월 현재 채팅 지원에 따르면 마이크로소프트 디펜더 바이러스 백신과 같이 "악성코드/악성으로 잘못 감지됨" 또는 "PUA(잠재적으로 원치 않는 응용 프로그램)로 잘못 감지됨"과 같은 오탐을 제출하는 알려진 메커니즘이 없는데, 이는 대충 처리하는 것을 의미할 수 있으며 응용 프로그램이 랜섬웨어 등으로 잘못 분류되는 원인이 될 수 있지만, 실제 위협을 감지하는 메커니즘은 명시되어 있지 않다.
트렌드 마이크로 인터넷 시큐리티
악성코드 방지 및 웹 위협 보호 외에도 이 소프트웨어의 프리미엄 버전에는 PC, Mac, 안드로이드 또는 iOS 모바일 장치 호환성, 자녀 보호 기능, 신원 도용 방지, 주요 소셜 네트워킹 사이트용 개인 정보 스캐너, 25GB의 클라우드 저장소가 포함된다.