shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
doas는 테드 우낭스트가 OpenBSD용으로 sudo를 더 간단하고 안전하게 대체하기 위해 개발했다. 우낭스트 자신은 기본 sudo 구성에 문제가 있었고, 이것이 doas를 개발하게 된 동기가 되었다. doas는 2015년 10월 OpenBSD 5.8과 함께 출시되어 sudo를 대체했다. 하지만 OpenBSD는 여전히 sudo를 패키지로 제공한다.
권한 정의는 구성 파일 /etc/doas.conf에 작성되어야 한다. 구성 파일에 사용되는 문법은 패킷 필터 구성 파일에서 영감을 받았다.
user1이 암호 없이 root로 procmap을 실행하도록 허용:
휠 그룹의 구성원이 root로 모든 명령을 실행하도록 허용:
더 간단한 버전 (기본 사용자가 root일 경우에만 작동하며, 설치 후에는 root이다):
휠 그룹의 구성원이 모든 명령(기본적으로 root)을 실행하고 암호를 입력했음을 기억하도록 허용:
포트 및 가용성.
제시 스미스(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)이다.
포어프론트에는 다음 제품이 포함된다.
포어프론트 서버 보호 제품의 전신은 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((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에 자세히 설명되어 있다.
24개 이상의 회사와 기관에서 약 30명의 개인이 SAML 2.0 생성에 참여했다. 특히 리버티 얼라이언스는 ID 연합 프레임워크(ID-FF) 사양을 OASIS에 기증했는데, 이 사양은 SAML 2.0 사양의 기반이 되었다. 따라서 SAML 2.0은 SAML 1.1, 리버티 ID-FF 1.2 , 그리고 시볼레스 1.3의 융합을 나타낸다.
SAML 2.0 어설션.
어설션은 SAML 기관이 만든 0개 이상의 문장을 제공하는 정보 패키지다. SAML 어설션은 일반적으로 codice_1 요소로 표현되는 주체에 대해 만들어진다. SAML 2.0 사양은 SAML 기관이 만들 수 있는 세 가지 유형의 어설션 문장을 정의한다. 모든 SAML 정의 문장은 주체와 관련이 있다. 세 가지 유형의 어설션 문장은 다음과 같이 정의된다.
SAML 어설션의 중요한 유형은 웹 브라우저 SSO를 용이하게 하는 소위 "전달자(bearer)" 어설션이다. 다음은 ID 공급자(https://idp.example.org/SAML2)가 서비스 공급자(https://sp.example.com/SAML2)에게 발급한 단기 전달자 어설션의 예시다. 이 어설션에는 서비스 공급자가 액세스 제어 결정을 내리는 데 사용하는 것으로 추정되는 인증 어설션 codice_2과 속성 어설션 codice_3이 모두 포함되어 있다. 접두사 codice_4은 SAML V2.0 어설션 네임스페이스를 나타낸다.
SAML 예시.
&lt;saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"&gt;
&lt;saml:Issuer&gt;https://idp.example.org/SAML2&lt;/saml:Issuer&gt;
&lt;ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;...&lt;/ds:Signature&gt;
&lt;saml:Subject&gt;
&lt;saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"&gt;
&lt;/saml:NameID&gt;
&lt;saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"&gt;
&lt;saml:SubjectConfirmationData
InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
Recipient="https://sp.example.com/SAML2/SSO/POST"
NotOnOrAfter="2004-12-05T09:27:05Z"/&gt;
&lt;/saml:SubjectConfirmation&gt;
&lt;/saml:Subject&gt;
&lt;saml:Conditions
NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z"&gt;
&lt;saml:AudienceRestriction&gt;
&lt;saml:Audience&gt;https://sp.example.com/SAML2&lt;/saml:Audience&gt;
&lt;/saml:AudienceRestriction&gt;
&lt;/saml:Conditions&gt;
&lt;saml:AuthnStatement
AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac"&gt;
&lt;saml:AuthnContext&gt;
&lt;saml:AuthnContextClassRef&gt;
&lt;/saml:AuthnContextClassRef&gt;
&lt;/saml:AuthnContext&gt;
&lt;/saml:AuthnStatement&gt;
&lt;saml:AttributeStatement&gt;
&lt;saml:Attribute
xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
x500:Encoding="LDAP"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation"&gt;
&lt;saml:AttributeValue
xsi:type="xs:string"&gt;member&lt;/saml:AttributeValue&gt;
xsi:type="xs:string"&gt;staff&lt;/saml:AttributeValue&gt;
&lt;/saml:Attribute&gt;
&lt;/saml:AttributeStatement&gt;
&lt;/saml:Assertion&gt;
위 예시에서 codice_5 요소에는 다음 자식 요소가 포함되어 있다.
간단히 말해, 어설션은 다음 정보를 인코딩한다.
어설션("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"에 발행되었다.
특히 인증 문은 다음을 주장한다.
codice_9 요소에서 식별된 주체는 보호된 채널을 통해 전송된 비밀번호를 사용하여 "2004-12-05T09:22:00Z"에 인증되었다.
마찬가지로 속성 문은 다음을 주장한다.
codice_9 요소에서 식별된 주체는 이 기관에서 '직원' 및 '멤버' 속성을 가지고 있다.
SAML 2.0 프로토콜.
다음 프로토콜은 SAMLCore에 지정되어 있다.
이 프로토콜 중 가장 중요한 인증 요청 프로토콜은 아래에 자세히 설명되어 있다.
인증 요청 프로토콜.
SAML 1.1 웹 브라우저 SSO 프로필에서는 ID 공급자(IDP)에 의해 시작된다. 즉, 비요청 codice_15 요소가 ID 공급자에서 서비스 공급자(브라우저를 통해)로 전송된다. (접두사 codice_16는 SAML 프로토콜 네임스페이스를 나타낸다.)
그러나 SAML 2.0에서는 서비스 공급자가 ID 공급자에게 명시적인 인증 요청을 발행하면서 흐름이 시작된다. 결과적으로 인증 요청 프로토콜은 SAML 2.0의 중요한 새로운 기능이다.
주체(또는 주체를 대신하여 작동하는 엔터티)가 인증 문을 포함하는 어설션을 얻으려는 경우 codice_17 요소가 ID 공급자에게 전송된다.
&lt;samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="aaf23196-1773-2113-474a-fe114412ab72"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="0"
AttributeConsumingServiceIndex="0"&gt;
&lt;saml:Issuer&gt;https://sp.example.com/SAML2&lt;/saml:Issuer&gt;
&lt;samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/&gt;
&lt;/samlp:AuthnRequest&gt;
명시적으로 인증 문을 포함하는 어설션을 요청하는 위의 codice_17 요소는 서비스 공급자(https://sp.example.com/SAML2)에 의해 발행된 후 ID 공급자(브라우저를 통해)에게 제시된 것으로 보인다. ID 공급자는 주체를 인증(필요한 경우)하고 인증 응답을 발행하여 서비스 공급자(다시 브라우저를 통해)에게 다시 전송한다.
아티팩트 해결 프로토콜.
SAML 메시지는 값으로 또는 참조로 한 엔터티에서 다른 엔터티로 전송된다. SAML 메시지에 대한 참조를 아티팩트라고 한다. 아티팩트의 수신자는 codice_19 요청을 아티팩트 발행자에게 직접 전송하여 참조를 해결한다. 그러면 발행자는 아티팩트가 참조하는 실제 메시지로 응답한다.
예를 들어, ID 공급자가 다음 codice_19 요청을 서비스 공급자에게 직접 전송한다고 가정하자(백 채널을 통해).
&lt;samlp:ArtifactResolve
ID="_cce4ee769ed970b501d680f697989d14"
IssueInstant="2004-12-05T09:21:58Z"&gt;
&lt;!-- an ArtifactResolve message SHOULD be signed --&gt;
&lt;samlp:Artifact&gt;AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=&lt;/samlp:Artifact&gt;
&lt;/samlp:ArtifactResolve&gt;
이에 응답하여 서비스 공급자는 포함된 아티팩트가 참조하는 SAML 요소를 반환한다. 이 프로토콜은 HTTP 아티팩트 바인딩의 기초를 형성한다.
SAML 2.0 바인딩.
SAML 2.0이 지원하는 바인딩은 바인딩 사양(SAMLBind)에 설명되어 있다.
웹 브라우저 SSO의 경우 HTTP 리다이렉트 바인딩과 HTTP POST 바인딩이 일반적으로 사용된다. 예를 들어, 서비스 공급자는 HTTP 리다이렉트를 사용하여 요청을 보내고 ID 공급자는 HTTP POST를 사용하여 응답을 전송할 수 있다. 이 예시는 엔터티의 바인딩 선택이 파트너의 바인딩 선택과 독립적임을 보여준다.
HTTP 리다이렉트 바인딩.
SAML 프로토콜 메시지는 HTTP GET 요청의 URL 쿼리 문자열에 직접 전송될 수 있다. 실제 URL 길이에 제한이 있으므로 HTTP 리다이렉트 바인딩은 codice_17 메시지와 같은 짧은 메시지에 적합하다. (SAML 응답과 같이 서명되거나 암호화된 SAML 어설션을 포함하는) 더 긴 메시지는 일반적으로 HTTP POST 바인딩과 같은 다른 바인딩을 통해 전송된다.
HTTP 리다이렉트를 통해 전송되는 SAML 요청 또는 응답은 각각 codice_22 또는 codice_23 쿼리 문자열 매개변수를 갖는다. 메시지가 전송되기 전에 메시지는 압축 해제 (헤더 및 체크섬 없음), base64 인코딩, URL 인코딩 순으로 처리된다. 수신 시에는 원래 메시지를 복구하기 위해 이 프로세스가 역순으로 수행된다.
예를 들어, 위 codice_17 메시지를 인코딩하면 다음이 생성된다.
위 메시지(가독성을 위해 서식 지정됨)는 추가 보안을 위해 서명될 수 있다. 실제로는 SP ID를 포함하는 codice_25 및 codice_26와 같이 codice_17에 포함된 모든 데이터는 IdP와 SP 간에 미리 합의된다(수동 정보 교환 또는 SAML 메타데이터를 통해). 이 경우 요청 서명은 보안 제약이 아니다. codice_17에 Assertion Consumer Service URL과 같이 IdP가 사전에 알지 못하는 정보가 포함된 경우 보안상의 이유로 요청에 서명하는 것이 권장된다.
HTTP POST 바인딩.
다음 예시에서는 서비스 공급자와 ID 공급자 모두 HTTP POST 바인딩을 사용한다. 처음에 서비스 공급자는 사용자 에이전트의 요청에 XHTML 양식이 포함된 문서로 응답한다.
&lt;form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...&gt;
&lt;input type="hidden" name="SAMLRequest" value="request" /&gt;
... other input parameter...
codice_22 매개변수의 값은 브라우저를 통해 ID 공급자에게 전송되는 codice_17 요소의 base64 인코딩이다. ID 공급자의 SSO 서비스는 요청을 검증하고 다른 XHTML 양식이 포함된 문서로 응답한다.
&lt;form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...&gt;
&lt;input type="hidden" name="SAMLResponse" value="response" /&gt;
codice_23 매개변수의 값은 마찬가지로 브라우저를 통해 서비스 공급자에게 전송되는 codice_15 요소의 base64 인코딩이다.
폼 제출을 자동화하려면 다음 자바스크립트 코드를 XHTML 페이지의 아무 곳에나 배치할 수 있다.
물론 이는 페이지의 첫 번째 폼 요소에 위의 SAMLResponse를 포함하는 codice_33 요소(codice_34)가 있다고 가정한다.
HTTP 아티팩트 바인딩.
HTTP 아티팩트 바인딩은 아티팩트 해결 프로토콜과 SAML SOAP 바인딩(HTTP를 통한)을 사용하여 참조를 통해 SAML 메시지를 해결한다. 다음 구체적인 예시를 살펴보자. 서비스 공급자가 ID 공급자에게 codice_17 메시지를 보내려고 한다고 가정하자. 처음에 서비스 공급자는 HTTP 리다이렉트를 통해 ID 공급자에게 아티팩트를 전송한다.
https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact
다음으로 ID 공급자는 백 채널을 통해 codice_19 요청(이전에 표시된 ArtifactResolveRequest와 같은)을 서비스 공급자에게 직접 보낸다. 마지막으로 서비스 공급자는 참조된 codice_17 메시지를 포함하는 codice_38 요소를 반환한다.
&lt;samlp:ArtifactResponse
ID="_d84a49e5958803dedcff4c984c2b0d95"
InResponseTo="_cce4ee769ed970b501d680f697989d14"
IssueInstant="2004-12-05T09:21:59Z"&gt;
&lt;!-- an ArtifactResponse message SHOULD be signed --&gt;
&lt;samlp:Status&gt;
&lt;samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/&gt;
&lt;/samlp:Status&gt;
ID="_306f8ec5b618f361c70b6ffb1480eade"
Destination="https://idp.example.org/SAML2/SSO/Artifact"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
AssertionConsumerServiceURL="https://sp.example.com/SAML2/SSO/Artifact"&gt;
AllowCreate="false"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/&gt;
&lt;/samlp:ArtifactResponse&gt;
물론 흐름은 다른 방향으로도 갈 수 있다. 즉, ID 공급자가 아티팩트를 발행할 수도 있으며, 사실 이것이 더 일반적이다. 예를 들어, 이 주제의 뒷부분에 나오는 "이중 아티팩트" 프로필 예시를 참조하자.
아티팩트 형식.
일반적으로 SAML 2.0 아티팩트는 다음과 같이 정의된다(SAMLBind).
TypeCode := Byte1Byte2
따라서 SAML 2.0 아티팩트는 세 가지 구성 요소로 구성된다. 2바이트 codice_39, 2바이트 codice_40, 그리고 codice_41라고 하는 임의의 바이트 시퀀스다. 이 세 가지 정보는 연결되어 base64 인코딩되어 완전한 아티팩트를 생성한다.
codice_39는 아티팩트 형식을 고유하게 식별한다. SAML 2.0은 유형 0x0004의 아티팩트 하나만 미리 정의한다. codice_40는 아티팩트 발행자(이전에 언급했듯이 IdP 또는 SP일 수 있음)가 관리하는 특정 아티팩트 해결 엔드포인트에 대한 참조다. 유형 정의에 의해 결정되는 codice_41는 아티팩트의 "핵심"이다.
유형 0x0004 아티팩트의 형식은 다음과 같이 추가로 정의된다.
TypeCode := 0x0004
RemainingArtifact := SourceId MessageHandle
SourceId := 20-byte_sequence
MessageHandle := 20-byte_sequence
따라서 유형 0x0004 아티팩트는 44바이트(인코딩되지 않음) 크기다. codice_45는 임의의 바이트 시퀀스지만, 실제로는 codice_45가 발행자의 entityID의 SHA-1 해시인 경우가 많다. codice_47은 아티팩트 발행자가 온디맨드로 생성할 수 있는 SAML 메시지를 참조하는 임의의 바이트 시퀀스다.
예를 들어, 다음 16진수 인코딩된 유형 0x0004 아티팩트를 고려하자.
00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f
자세히 보면 아티팩트 앞부분에 codice_39 (0x0004)와 codice_40 (0x0000)를 볼 수 있다. 다음 20바이트는 발행자의 entityID(https://idp.example.org/SAML2)의 SHA-1 해시이며, 그 뒤에 20개의 임의 바이트가 온다. 이 44바이트의 base64 인코딩이 위 ArtifactResolveRequest 예시에서 볼 수 있는 내용이다.
SAML 2.0 프로필.
SAML 2.0은 SAML 1.1과 마찬가지로 여전히 웹 브라우저 SSO가 주요 사용 사례지만, SAML 2.0의 범위는 다음의 광범위한 프로필 목록에서 알 수 있듯이 이전 SAML 버전보다 더 넓다.
지원되는 프로필 수가 상당히 많지만, 각 프로필의 바인딩 측면이 별도의 바인딩 사양(SAMLBind)으로 분리되었으므로 프로필 사양(SAMLProf)은 간소화되었다.
웹 브라우저 SSO 프로필.
SAML 2.0은 ID 공급자(IdP), 서비스 공급자(SP) 및 HTTP 사용자 에이전트를 사용하는 주체를 포함하는 웹 브라우저 SSO 프로필을 지정한다. 서비스 공급자는 네 가지 바인딩 중에서 선택할 수 있으며, ID 공급자는 세 가지 바인딩 중에서 선택할 수 있어 12가지 가능한 배포 시나리오가 발생한다. 아래에서는 세 가지 배포 시나리오를 설명한다.
SP 리다이렉트 요청; IdP POST 응답.
이것은 가장 일반적인 시나리오 중 하나다. 서비스 공급자는 HTTP-리다이렉트 바인딩을 사용하여 SAML 요청을 IdP SSO 서비스로 보낸다. ID 공급자는 HTTP-POST 바인딩을 사용하여 SAML 응답을 SP 어설션 소비자 서비스로 반환한다.
메시지 흐름은 서비스 공급자의 보안 리소스 요청으로 시작된다.
1. SP에서 대상 리소스 요청
주체(HTTP 사용자 에이전트를 통해)는 서비스 공급자에서 대상 리소스를 요청한다.
서비스 공급자는 대상 리소스를 대신하여 보안 검사를 수행한다. 서비스 공급자에 유효한 보안 컨텍스트가 이미 존재하면 2-7단계를 건너뛴다.
서비스 공급자는 사용될 ID 공급자를 발견하기 위해 사용자에게 질문하거나 미리 구성된 IdP를 사용하는 등 모든 종류의 메커니즘을 사용할 수 있다.
2. IdP SSO 서비스로 리다이렉트
서비스 공급자는 적절한 SAMLRequest(및 RelayState, 있는 경우)를 생성한 다음 표준 HTTP 302 리다이렉트를 사용하여 브라우저를 IdP SSO 서비스로 리다이렉트한다.
302 Redirect
Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&amp;RelayState=token
codice_50 토큰은 서비스 공급자에서 유지 관리되는 상태 정보에 대한 불투명한 참조다. codice_22 매개변수의 값은 codice_17 요소의 압축 해제, base64 인코딩 및 URL 인코딩된 값이다.
ID="identifier_1"
AssertionConsumerServiceIndex="0"&gt;
SAMLRequest는 SP 서명 키를 사용하여 서명될 수 있다. 그러나 일반적으로 이는 필요하지 않다.
3. IdP에서 SSO 서비스 요청
사용자 에이전트는 ID 공급자의 SSO 서비스에 GET 요청을 발행한다.
GET /SAML2/SSO/Redirect?SAMLRequest=request&amp;RelayState=token HTTP/1.1
Host: idp.example.org
여기서 codice_22 및 codice_50 매개변수의 값은 리다이렉트에서 제공된 값과 동일하다. ID 공급자의 SSO 서비스는 codice_17 요소를 처리(URL 디코딩, base64 디코딩, 압축 해제 순서로)하고 보안 검사를 수행한다. 사용자에게 유효한 보안 컨텍스트가 없으면 ID 공급자는 임의의 메커니즘(세부 정보 생략)으로 사용자를 식별한다.
4. XHTML 양식으로 응답
SSO 서비스는 요청을 검증하고 XHTML 양식이 포함된 문서로 응답한다.
&lt;input type="hidden" name="RelayState" value="token" /&gt;
&lt;input type="submit" value="Submit" /&gt;
codice_50 매개변수 값은 3단계에서 보존되었다. codice_23 매개변수 값은 다음 codice_15 요소의 base64 인코딩이다.
&lt;samlp:Response
ID="identifier_2"
InResponseTo="identifier_1"
IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.com/SAML2/SSO/POST"&gt;
ID="identifier_3"
&lt;!-- a POSTed assertion MUST be signed --&gt;
SessionIndex="identifier_3"&gt;
&lt;/samlp:Response&gt;
5. SP에서 어설션 소비자 서비스 요청
사용자 에이전트는 서비스 공급자의 어설션 소비자 서비스에 POST 요청을 발행한다.
POST /SAML2/SSO/POST HTTP/1.1
Host: sp.example.com
Content-Length: nnn
SAMLResponse=response&amp;RelayState=token
여기서 codice_23 및 codice_50 매개변수의 값은 4단계의 XHTML 양식에서 가져온다.
6. 대상 리소스로 리다이렉트
어설션 소비자 서비스는 응답을 처리하고 서비스 공급자에 보안 컨텍스트를 생성한 다음 사용자 에이전트를 대상 리소스로 리다이렉트한다.
7. SP에서 대상 리소스 다시 요청
사용자 에이전트는 서비스 공급자에서 대상 리소스를 다시 요청한다.
8. 요청된 리소스로 응답
보안 컨텍스트가 존재하므로 서비스 공급자는 리소스를 사용자 에이전트에 반환한다.
SP POST 요청; IdP POST 응답.
이것은 서비스 공급자(SP)와 ID 공급자(IdP) 모두 HTTP POST 바인딩을 사용하는 SAML 2.0 웹 브라우저 SSO 프로필(SAMLProf)의 비교적 간단한 배포다.
메시지 흐름은 SP의 보안 리소스 요청으로 시작된다.
2. XHTML 양식으로 응답
서비스 공급자는 XHTML 양식이 포함된 문서로 응답한다.
codice_50 토큰은 서비스 공급자에서 유지 관리되는 상태 정보에 대한 불투명한 참조다. codice_22 매개변수의 값은 다음 codice_17 요소의 base64 인코딩이다.
codice_17 요소가 XHTML 양식에 삽입되기 전에 먼저 base64 인코딩된다.
사용자 에이전트는 ID 공급자의 SSO 서비스에 POST 요청을 발행한다.
SAMLRequest=request&amp;RelayState=token
여기서 codice_22 및 codice_50 매개변수의 값은 2단계의 XHTML 양식에서 가져온다. SSO 서비스는 codice_17 요소를 처리(URL 디코딩, base64 디코딩, 압축 해제 순서로)하고 보안 검사를 수행한다. 사용자에게 유효한 보안 컨텍스트가 없으면 ID 공급자는 사용자를 식별한다(세부 정보 생략).
SP 리다이렉트 아티팩트; IdP 리다이렉트 아티팩트.
이것은 서비스 공급자(SP)와 ID 공급자(IdP) 모두 HTTP 아티팩트 바인딩을 사용하는 SAML 2.0 웹 브라우저 SSO 프로필(SAMLProf)의 복잡한 배포다. 두 아티팩트 모두 HTTP GET을 통해 해당 엔드포인트로 전달된다.
서비스 공급자는 대상 리소스를 대신하여 보안 검사를 수행한다. 서비스 공급자에 유효한 보안 컨텍스트가 이미 존재하면 2-11단계를 건너뛴다.
2. IdP의 단일 로그인(SSO) 서비스로 리다이렉트
서비스 공급자는 사용자 에이전트를 ID 공급자의 단일 로그인(SSO) 서비스로 리다이렉트한다. codice_50 매개변수와 codice_74 매개변수가 리다이렉트 URL에 추가된다.
사용자 에이전트는 ID 공급자의 SSO 서비스를 요청한다.
https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact_1&amp;RelayState=token
여기서 codice_75은 서비스 공급자에서 유지 관리되는 상태 정보에 대한 불투명한 참조이고, codice_76은 2단계에서 발행된 SAML 아티팩트다.
4. SP에서 아티팩트 해결 서비스 요청
SSO 서비스는 codice_19 요소를 SAML SOAP 메시지에 바인딩하여 서비스 공급자의 아티팩트 해결 서비스에 전송함으로써 아티팩트의 참조를 해제한다.
IssueInstant="2004-12-05T09:21:58Z"
Destination="https://sp.example.com/SAML2/ArtifactResolution"&gt;
&lt;samlp:Artifact&gt;artifact_1&lt;/samlp:Artifact&gt;
여기서 codice_78 요소의 값은 3단계에서 전송된 SAML 아티팩트다.
5. SAML AuthnRequest로 응답
서비스 공급자의 아티팩트 해결 서비스는 codice_38 요소(codice_17 요소 포함)를 SAML SOAP 메시지에 바인딩하여 ID 공급자의 SSO 서비스에 반환한다.
SSO 서비스는 codice_17 요소를 처리하고 보안 검사를 수행한다. 사용자에게 유효한 보안 컨텍스트가 없으면 ID 공급자는 사용자를 식별한다(세부 정보 생략).
6. 어설션 소비자 서비스로 리다이렉트
ID 공급자의 SSO 서비스는 사용자 에이전트를 서비스 공급자의 어설션 소비자 서비스로 리다이렉트한다. 이전 codice_50 매개변수와 새 codice_74 매개변수가 리다이렉트 URL에 추가된다.
7. SP에서 어설션 소비자 서비스 요청
사용자 에이전트는 서비스 공급자의 어설션 소비자 서비스를 요청한다.
https://sp.example.com/SAML2/SSO/Artifact?SAMLart=artifact_2&amp;RelayState=token
여기서 codice_75은 3단계의 토큰 값이고, codice_85는 6단계에서 발행된 SAML 아티팩트다.
8. IdP에서 아티팩트 해결 서비스 요청
어설션 소비자 서비스는 codice_19 요소를 SAML SOAP 메시지에 바인딩하여 ID 공급자의 아티팩트 해결 서비스에 전송함으로써 아티팩트의 참조를 해제한다.
ID="identifier_4"
IssueInstant="2004-12-05T09:22:04Z"
Destination="https://idp.example.org/SAML2/ArtifactResolution"&gt;
&lt;samlp:Artifact&gt;artifact_2&lt;/samlp:Artifact&gt;
여기서 codice_78 요소의 값은 7단계에서 전송된 SAML 아티팩트다.
9. SAML 어설션으로 응답
ID 공급자의 아티팩트 해결 서비스는 codice_38 요소(codice_15 요소 포함)를 SAML SOAP 메시지에 바인딩하여 서비스 공급자의 어설션 소비자 서비스에 반환한다.
ID="identifier_5"
InResponseTo="identifier_4"
ID="identifier_6"
InResponseTo="identifier_3"
Destination="https://sp.example.com/SAML2/SSO/Artifact"&gt;
ID="identifier_7"
&lt;!-- a Subject element is required --&gt;
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"&gt;
user@mail.example.org
Recipient="https://sp.example.com/SAML2/SSO/Artifact"
SessionIndex="identifier_7"&gt;
10. 대상 리소스로 리다이렉트
11. SP에서 대상 리소스 다시 요청
12. 요청된 리소스로 응답
ID 공급자 발견 프로필.
SAML 2.0 ID 공급자 발견 프로필은 다음 개념을 소개한다.
가상의 공통 도메인 예시로, 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 속성 질의.
속성 질의는 아마도 가장 중요한 유형의 SAML 질의일 것이다. 종종 주체를 대신하여 요청자가 속성을 ID 공급자에게 질의한다. 아래에서는 주체가 직접 발행한 질의의 예시를 보여준다.
&lt;samlp:AttributeQuery
IssueInstant="2006-07-17T20:31:40Z"&gt;
&lt;saml:Issuer
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"&gt;
CN=trscavo@example.com,OU=User,O=NCSA-TEST,C=US
&lt;/saml:Issuer&gt;
Name="urn:oid:2.5.4.42"
FriendlyName="givenName"&gt;
Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26"
FriendlyName="mail"&gt;
&lt;/samlp:AttributeQuery&gt;
이 경우 codice_25가 codice_97임을 주목하자. 이것을 속성 자체 질의(attribute self-query)라고 부르기도 한다. ID 공급자는 codice_15 요소(표시되지 않음)에 래핑된 다음 어설션을 반환할 수 있다.
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
ID="_33776a319493ad607b7ab3e689482e45"
IssueInstant="2006-07-17T20:31:41Z"&gt;
&lt;ds:Signature&gt;...&lt;/ds:Signature&gt;
Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"&gt;
&lt;saml:SubjectConfirmationData&gt;
&lt;ds:KeyInfo&gt;
&lt;ds:X509Data&gt;
&lt;!-- principal's X.509 cert --&gt;
&lt;ds:X509Certificate&gt;
MIICiDCCAXACCQDE+9eiWrm62jANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJV
UzESMBAGA1UEChMJTkNTQS1URVNUMQ0wCwYDVQQLEwRVc2VyMRMwEQYDVQQDEwpT
UC1TZXJ2aWNlMB4XDTA2MDcxNzIwMjE0MVoXDTA2MDcxODIwMjE0MVowSzELMAkG
A1UEBhMCVVMxEjAQBgNVBAoTCU5DU0EtVEVTVDENMAsGA1UECxMEVXNlcjEZMBcG
A1UEAwwQdHJzY2F2b0B1aXVjLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEAv9QMe4lRl3XbWPcflbCjGK9gty6zBJmp+tsaJINM0VaBaZ3t+tSXknelYife
nCc2O3yaX76aq53QMXy+5wKQYe8Rzdw28Nv3a73wfjXJXoUhGkvERcscs9EfIWcC
g2bHOg8uSh+Fbv3lHih4lBJ5MCS2buJfsR7dlr/xsadU2RcCAwEAATANBgkqhkiG
9w0BAQQFAAOCAQEAdyIcMTob7TVkelfJ7+I1j0LO24UlKvbLzd2OPvcFTCv6fVHx
Ejk0QxaZXJhreZ6+rIdiMXrEzlRdJEsNMxtDW8++sVp6avoB5EX1y3ez+CEAIL4g
cjvKZUR4dMryWshWIBHKFFul+r7urUgvWI12KbMeE9KP+kiiiiTskLcKgFzngw1J
selmHhTcTCrcDocn5yO2+d3dog52vSOtVFDBsBuvDixO2hv679JR6Hlqjtk4GExp
E9iVI0wdPE038uQIJJTXlhsMMLvUGVh/c0ReJBn92Vj4dI/yy6PtY/8ncYLYNkjg
oVN0J/ymOktn9lTlFyTiuY4OuJsZRO1+zWLy9g==
&lt;/ds:X509Certificate&gt;
&lt;/ds:X509Data&gt;
&lt;/ds:KeyInfo&gt;
&lt;/saml:SubjectConfirmationData&gt;
&lt;!-- assertion lifetime constrained by principal's X.509 cert --&gt;
NotBefore="2006-07-17T20:31:41Z"
NotOnOrAfter="2006-07-18T20:21:41Z"&gt;
AuthnInstant="2006-07-17T20:31:41Z"&gt;
urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
xsi:type="xs:string"&gt;Tom&lt;/saml:AttributeValue&gt;
xsi:type="xs:string"&gt;trscavo@example.org&lt;/saml:AttributeValue&gt;
이전에 표시된 전달자 어설션과 대조적으로, 이 어설션은 주체가 ID 공급자에 인증하는 데 사용한 X.509 인증서의 수명에 해당하는 더 긴 수명을 갖는다. 또한 어설션이 서명되었으므로 사용자는 이 어설션을 의존 당사자에게 푸시할 수 있으며, 사용자가 해당 개인 키의 소유를 증명할 수 있는 한("홀더-오브-키"라는 이름이 붙은 이유) 의존 당사자는 어설션이 정품임을 확신할 수 있다.
SAML 2.0 메타데이터.
말 그대로 메타데이터는 SAML이 작동(또는 잘 작동)하게 하는 요소다. 메타데이터의 몇 가지 중요한 용도는 다음과 같다.
메타데이터는 ID 공급자와 서비스 공급자 간의 안전한 트랜잭션을 보장한다. 메타데이터 이전에는 신뢰 정보가 독점적인 방식으로 구현에 인코딩되었다. 이제 신뢰 정보 공유는 표준 메타데이터를 통해 용이해졌다. SAML 2.0은 엔터티가 신뢰 프로세스를 부트스트랩하는 데 활용할 수 있는 잘 정의되고 상호 운용 가능한 메타데이터 형식을 제공한다.
ID 공급자 메타데이터.
ID 공급자는 codice_101 요소에 자신에 대한 데이터를 게시한다.
&lt;md:EntityDescriptor entityID="https://idp.example.org/SAML2" validUntil="2013-03-22T23:00:00Z"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
&lt;!-- insert ds:Signature element (omitted) --&gt;
&lt;!-- insert md:IDPSSODescriptor element (below) --&gt;
&lt;md:Organization&gt;
&lt;md:OrganizationName xml:lang="en"&gt;Some Non-profit Organization of New York&lt;/md:OrganizationName&gt;
&lt;md:OrganizationDisplayName xml:lang="en"&gt;Some Non-profit Organization&lt;/md:OrganizationDisplayName&gt;
&lt;md:OrganizationURL xml:lang="en"&gt;https://www.example.org/&lt;/md:OrganizationURL&gt;
&lt;/md:Organization&gt;
&lt;md:ContactPerson contactType="technical"&gt;
&lt;md:SurName&gt;SAML Technical Support&lt;/md:SurName&gt;
&lt;md:EmailAddress&gt;mailto:saml-support@example.org&lt;/md:EmailAddress&gt;
&lt;/md:ContactPerson&gt;
&lt;/md:EntityDescriptor&gt;
이 엔터티 디스크립터에 대한 다음 세부 사항에 주목하자.
정의상 ID 공급자는 SAMLProf에 지정된 SAML 웹 브라우저 SSO 프로필을 지원하는 SSO 서비스를 관리한다. 예를 들어 다음 섹션에 표시된 codice_107 요소에 설명된 ID 공급자를 참조하자.
SSO 서비스 메타데이터.
ID 공급자의 SSO 서비스는 codice_107 요소에 설명되어 있다.
&lt;md:IDPSSODescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"&gt;
&lt;md:KeyDescriptor use="signing"&gt;
&lt;ds:KeyInfo&gt;...&lt;/ds:KeyInfo&gt;
&lt;/md:KeyDescriptor&gt;
&lt;md:ArtifactResolutionService isDefault="true" index="0"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="https://idp.example.org/SAML2/ArtifactResolution"/&gt;
&lt;md:NameIDFormat&gt;urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress&lt;/md:NameIDFormat&gt;
&lt;md:NameIDFormat&gt;urn:oasis:names:tc:SAML:2.0:nameid-format:transient&lt;/md:NameIDFormat&gt;
&lt;md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://idp.example.org/SAML2/SSO/Redirect"/&gt;
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://idp.example.org/SAML2/SSO/POST"/&gt;
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
Location="https://idp.example.org/SAML2/Artifact"/&gt;
&lt;saml:AttributeValue&gt;member&lt;/saml:AttributeValue&gt;
&lt;saml:AttributeValue&gt;student&lt;/saml:AttributeValue&gt;
&lt;saml:AttributeValue&gt;faculty&lt;/saml:AttributeValue&gt;
&lt;saml:AttributeValue&gt;employee&lt;/saml:AttributeValue&gt;
&lt;saml:AttributeValue&gt;staff&lt;/saml:AttributeValue&gt;
&lt;/md:IDPSSODescriptor&gt;
이전 메타데이터 요소는 ID 공급자의 SSO 서비스를 설명한다. 이 요소에 대한 다음 세부 사항에 주목하자.
이 섹션 시작 부분에 언급된 대로, codice_113 속성 값은 서비스 공급자가 SAML 메시지를 라우팅하는 데 사용되며, 이는 악의적인 ID 공급자가 중간자 공격을 조직할 가능성을 최소화한다.
서비스 공급자 메타데이터.
ID 공급자와 마찬가지로 서비스 공급자도 codice_101 요소에 자신에 대한 데이터를 게시한다.
&lt;md:EntityDescriptor entityID="https://sp.example.com/SAML2" validUntil="2013-03-22T23:00:00Z"
&lt;!-- insert md:SPSSODescriptor element (see below) --&gt;
&lt;md:OrganizationName xml:lang="en"&gt;Some Commercial Vendor of California&lt;/md:OrganizationName&gt;
&lt;md:OrganizationDisplayName xml:lang="en"&gt;Some Commercial Vendor&lt;/md:OrganizationDisplayName&gt;
&lt;md:OrganizationURL xml:lang="en"&gt;https://www.example.com/&lt;/md:OrganizationURL&gt;
&lt;md:EmailAddress&gt;mailto:saml-support@example.com&lt;/md:EmailAddress&gt;
정의상 서비스 공급자는 SAMLProf에 지정된 SAML 웹 브라우저 SSO 프로필을 지원하는 어설션 소비자 서비스를 관리한다. 예를 들어 다음 섹션에 표시된 codice_133 요소에 설명된 서비스 공급자를 참조하자.
어설션 소비자 서비스 메타데이터.
어설션 소비자 서비스는 codice_133 요소에 포함되어 있다.
&lt;md:SPSSODescriptor
&lt;md:KeyDescriptor use="encryption"&gt;
Location="https://sp.example.com/SAML2/ArtifactResolution"/&gt;