SP 대 IdP 시작 SSO

이 문서에서는 두 통합 배포 간의 SP 및 IdP 시작 SSO 개념과 이러한 두 플로우 간의 차이점에 대해 설명합니다.

이 문서에서는 페더레이션 SSO 중 IdP와 SP 간에 공유되는 사용자 상태 또는 반환 URL의 개념에 대해서도 설명합니다.

• SAML 1.1용 SAML 2.0 대상 RelayState WS-Fed 1.1용 wctx

• OpenID 2.0의 경우 openid.return_to(반환 SSO)

• URL에는 SP의 사용자 상태를 나타내는 질의 매개변수가 포함될 수 있음)

이 문서에서는 다른 프로토콜에도 동일하게 적용되지만 SAML 2.0 프로토콜을 사용하는 예를 보여줍니다.

통합 SSO 흐름

토폴로지

일반적인 통합 배치는 다음 엔티티로 구성됩니다.

• 사용자에게 계정이 있고 인증이 발생하는 IdP 서버에 대한 보안 도메인

• SP 서버의 보안 도메인

  • SP 통합 서버

  • SSO 서버(SSO 서버와 SP Federation Server가 동일한 엔티티인 경우)

  • SSO 서버와 통합된 SSO 웹 에이전트로, 리소스를 보호하고 사용자가 인증되고 리소스에 액세스할 수 있도록 권한이 부여됩니다. 이 작업을 수행하지 못하면 인증 플로우 또는 권한 부여 실패가 발생할 수 있습니다.

  • 리소스 또는 웹 응용 프로그램

  

  그림 Federation_deployment_Screen.jpg 설명

SP 시작 SSO

SP 시작 SSO 플로우는 SP 통합 서버에서 통합 인증 요청을 생성하고 메시지와 작업 상태를 나타내는 일부 짧은 문자열을 사용하여 사용자를 IdP로 재지정하여 SP 보안 도메인에서 시작된 통합 SSO 작업입니다.

• 통합 인증 요청은 사용되는 프로토콜에 따라 다릅니다.

  • 샘 2.0: AuthnRequest

  • SAML 1.1: SP를 나타내는 매개변수가 포함된 URL

  • WS-Fed: SP 및 기타 선택적 매개변수를 나타내는 wtrealm 매개변수가 포함된 URL

  • OpenID 2.0: OpenID 2.0 요청

• 작업 상태(사용자가 통합 SSO 작업을 시작하기 전에 수행 중이었던 작업)는 전체 상태가 아니라 SP Server 런타임 저장소의 상태에 대한 포인터로 사용자와 함께 IdP로 전송된 메시지에 전달됩니다. 이 정보는 프로토콜에 따라 다르게 전달됩니다.

  • SAML 2.0: RelayState 매개변수

  • SAML 1.1: TARGET 매개변수

  • WS-Fed: wctx 매개변수

  • OpenID 2.0: openid.return_to 매개변수로, IdP에서 인증 후 사용자가 재지정되는 SP URL로, SP에서 런타임 시 생성되며 작동 상태를 참조하는 질의 매개변수를 포함할 수 있습니다.

작동 상태에 대한 참고 사항: 일반적으로 재지정 URL 길이가 브라우저가 URL에 대해 처리할 수 있는 최대 길이를 초과하는 재지정 플로우가 손상될 수 있으므로 메시지에서 공유되는 상태가 너무 길지 않아야 합니다. 따라서 SP가 시작되는 SSO 동안에는 항상 SP를 사용하는 것이 좋습니다.

• SP의 메모리/DB 스토리지에 작동 상태 저장

• RelayState/TARGET/wctx로 작동 상태에 대한 포인터를 전송합니다.

SP 시작 SSO 플로우를 트리거하는 방법은 다음 두 가지입니다.

• 사용자가 통합 SSO 플로우를 시작하는 리소스에 대한 액세스를 요청합니다. 통합 SSO 작업이 수행되면 사용자는 처음에 요청된 리소스로 다시 재지정됩니다.

• 또는 사용자가 SP 서버에서 직접 서비스에 액세스하여 특히 원격 IdP를 사용하여 통합 SSO 플로우를 시작합니다. 이 경우 사용자는 일반적으로 통합 SSO 작업이 수행된 후 사용자가 재지정되어야 하는 URL을 제공합니다.

리소스 액세스

이는 사용자가 보호된 리소스에 액세스하려고 시도하는 통합 SSO 작업의 가장 일반적인 흐름이며, 런타임 시 SSO 시스템은 사용자가 통합 SSO를 통해 인증되어야 함을 결정합니다.

이 플로우가 사용되는 사용 사례는 다음과 같습니다.

• 사용자가 보호된 리소스를 참조하는 페이지에서 링크를 누름

• 사용자가 포털 페이지에서 보호된 리소스를 참조하는 링크를 누름

• 사용자에게 보호된 리소스에 대한 책갈피가 있습니다.

플로우에는 다음 단계가 포함됩니다.

1. 사용자의 브라우저가 보호된 리소스에 대한 액세스 요청

2. SSO 웹 에이전트가 호출을 가로채서 사용자를 인증해야 하는지 확인하고 사용자의 브라우저로 재지정을 다시 보냅니다.

3. 사용자의 브라우저가 SSO 웹 에이전트에 의해 재지정되는 SSO 서버에 액세스합니다.

4. SSO 서버는 사용자가 통합 SSO를 통해 인증되어야 함을 확인하고, IdP을 선택하고, SAML 2.0 AuthnRequest 메시지를 생성하고, SSO 서버 저장소에 작동 상태를 저장하고, SAML 메시지 및 SP의 작동 상태를 참조하는 문자열을 사용하여 사용자의 브라우저를 IdP로 재지정합니다.

5. 사용자 브라우저는 AuthnRequest 메시지와 함께 IdP SAML 2.0 서비스에 액세스합니다.

그림 Accessing_Resources_Screen.jpg 설명

IdP가 SAML 2.0 AuthnRequest 메시지를 받으면 서버는 사용자에게 도전해야 하는지 여부를 결정합니다(아직 인증되지 않은 세션 시간 초과...). 사용자를 식별할 수 있게 되면 통합 SSO 흐름이 재개됩니다.

1. IdP는 인증 데이터와 함께 사용자 정보를 포함하는 SAML 2.0 검증이 포함된 SSO 응답을 생성하고 메시지 및 RelayState 매개변수를 사용하여 사용자의 브라우저를 SP로 재지정합니다.

2. 사용자의 브라우저가 SP 서버에 SSO 응답을 표시합니다.

3. SP는 SAML 2.0 검증을 검증하고 사용자에 대한 SSO 세션을 생성합니다. 그러면 SSO 서버가 사용자의 브라우저를 원래 요청된 리소스로 다시 재지정합니다.

4. 사용자의 브라우저가 리소스에 대한 액세스를 요청합니다. 이번에는 SSO 웹 에이전트가 리소스에 대한 액세스 권한을 부여합니다.

5. 웹 응용 프로그램은 사용자의 브라우저에 응답을 반환합니다.

그림 Accessing_Resources_Response_Screen.jpg 설명

앞서 설명한 것처럼 페더레이션 SSO는 SP 보안 도메인의 다른 구성 요소 없이 런타임 시 SSO 서버에 의해서만 트리거되므로 페더레이션을 인식할 필요가 없으므로 이 흐름은 가장 일반적으로 사용됩니다.

페더레이션 SP 서비스 호출

이 흐름은 SP 서버의 서비스에 액세스하여 SP에서 페더레이션 SSO가 시작되고 사용자가 이미 가질 수 있는 기존의 유효한 세션을 무시함으로써 널리 사용되지 않습니다. 따라서 성능에 영향을 주므로 이렇게 하는 것은 피해야 합니다.

• 페더레이션 SSO 서버는 비용이 많이 듭니다(일부 프로토콜의 경우 XML, 메시지를 보호하기 위한 디지털 서명, 서버 간 통신).

• 브라우저로서의 사용자 환경이 여러 도메인으로 리디렉션되어 사용자가 대상으로 지정된 보호 리소스에 액세스하기 전에 지연이 발생합니다.

이 플로우가 사용되는 사용 사례는 다음과 같습니다.

• 사용자가 보호된 리소스를 참조하는 페이지에서 링크를 누름(일반적이지 않음)

• 사용자가 포털 페이지에서 보호된 리소스를 참조하는 링크를 누름

이 플로우가 사용되는 사용 사례는 다음 단계로 구성됩니다.

1. 사용자의 브라우저는 필요에 따라 다음을 지정하여 SP에 액세스하여 통합 SSO 플로우를 시작합니다.

   1. 통합 SSO가 완료된 후 사용자의 브라우저가 재지정되는 URL입니다.

   2. 사용할 IdP

2. SSO 서버는 제공되지 않은 경우 IdP를 선택하고, 제공되지 않은 경우 기본 반환 URL을 선택하고, SAML 2.0 AuthnRequest 메시지를 생성하고, SSO 서버 저장소에 작동 상태를 저장하고, SAML 메시지 및 SP의 작동 상태를 참조하는 문자열을 사용하여 사용자의 브라우저를 IdP로 재지정합니다.

3. 사용자 브라우저는 AuthnRequest 메시지와 함께 IdP SAML 2.0 서비스에 액세스합니다.

그림 IdP_Service_with_AuthnRequest_Screen.jpg 설명

IdP가 SAML 2.0 AuthnRequest 메시지를 받으면 서버는 사용자에게 도전해야 하는지 여부를 결정합니다(아직 인증되지 않은 세션 시간 초과...). 사용자를 식별할 수 있게 되면 통합 SSO 흐름이 재개됩니다.

1. IdP는 인증 데이터와 함께 사용자 정보를 포함하는 SAML 2.0 검증이 포함된 SSO 응답을 생성하고 메시지 및 RelayState 매개변수를 사용하여 사용자의 브라우저를 SP로 재지정합니다.

2. 사용자의 브라우저가 SP 서버에 SSO 응답을 표시합니다.

3. SP는 SAML 2.0 검증을 검증하고 사용자에 대한 SSO 세션을 생성합니다. 그러면 SSO 서버가 사용자의 브라우저를 원래 요청된 리소스로 다시 재지정합니다.

4. 사용자의 브라우저가 리소스에 대한 액세스를 요청합니다. 이번에는 SSO 웹 에이전트가 리소스에 대한 액세스 권한을 부여합니다.

5. 웹 응용 프로그램은 사용자의 브라우저에 응답을 반환합니다.

그림 IdP_Service_with_Response_Screen.jpg 설명

사용자에게 이미 유효한 SSO 세션이 있는 경우에도 통합 SSO가 정적으로 트리거되므로 이 흐름은 거의 사용되지 않습니다. 또한 이는 SP 보안 도메인의 일부 구성 요소가 SP 서비스를 인식해야 함을 의미합니다.

IdP SSO 시작

IdP 시작된 SSO 플로우는 IdP 보안 도메인에서 시작된 통합 SSO 작업으로, IdP 통합 서버에서 통합 SSO 응답을 생성하고 응답 메시지와 선택적 작동 상태를 사용하여 사용자를 SP로 재지정합니다.

• 통합 SSO 응답은 사용되는 프로토콜에 따라 다릅니다.

  • SAML 2.0: 검증이 있는 SAMLResponse

  • SAML 1.1: 검증이 있는 응답

  • WS-Fed: 검증을 통한 응답

  • OpenID 2.0: OpenID 2.0 응답

• 이 플로우의 선택적 작업 상태는 SP에서 통합 SSO가 완료된 후 사용자가 재지정되어야 하는 URL을 전달합니다. 누락된 경우 SP에서 사용자가 재지정될 위치를 결정해야 합니다. 이 정보는 프로토콜에 따라 다르게 전달됩니다.

  • SAML 2.0: RelayState 매개변수

  • SAML 1.1: TARGET 매개변수

  • WS-Fed: wctx 매개변수 OpenID 2.0: 이 프로토콜은 IdP 시작된 SSO 플로우를 지원하지 않습니다.

이전 절에서 설명했듯이 재지정 URL 길이가 브라우저가 URL에 대해 처리할 수 있는 최대 길이를 초과하는 재지정 플로우가 손상될 수 있으므로 메시지에서 공유되는 상태가 너무 길지 않아야 합니다.

이 흐름은 일반적으로 IdP 사용자가 SP에서 호스트하는 리소스에 액세스해야 하지만 페더레이션 SSO에 대한 최상의 접근 방법이 아닌 경우 사용됩니다. 페더레이션 SSO는 사용자가 이미 가질 수 있는 SP의 기존 유효 세션을 무시합니다. 따라서 성능에 영향을 주므로 이렇게 하는 것은 피해야 합니다.

• 페더레이션 SSO 서버는 비용이 많이 듭니다(일부 프로토콜의 경우 XML, 메시지를 보호하기 위한 디지털 서명, 서버 간 통신).

• 브라우저로서의 사용자 환경이 여러 도메인으로 리디렉션되어 사용자가 대상으로 지정된 보호 리소스에 액세스하기 전에 지연이 발생합니다.

이 플로우가 사용되는 사용 사례는 다음과 같습니다.

• 사용자가 SP의 보호된 리소스를 참조하는 IdP 포털 페이지에서 링크를 누릅니다.

이 플로우가 사용되는 사용 사례는 다음 단계로 구성됩니다.

1. 사용자의 브라우저는 다음을 지정하여 IdP에 액세스하여 통합 SSO 플로우를 시작합니다.

   1. 사용할 SP

   2. 필요에 따라 통합 SSO가 완료된 후 사용자의 브라우저가 재지정되는 URL입니다.

2. 사용자를 식별한 후 IdP는 사용자 정보와 인증 데이터를 포함하는 SAML 2.0 검증이 포함된 SSO 응답을 생성하고, 메시지와 RelayState 매개변수를 사용하여 사용자의 브라우저를 SP로 재지정합니다.

3. 사용자의 브라우저가 SP 서버에 SSO 응답을 표시합니다.

4. SP는 SAML 2.0 검증을 검증하고 사용자에 대한 SSO 세션을 생성합니다. 그러면 SSO 서버가 사용자의 브라우저를 원래 요청된 리소스로 다시 재지정합니다.

5. 사용자의 브라우저가 리소스에 대한 액세스를 요청합니다. 이번에는 SSO 웹 에이전트가 리소스에 대한 액세스 권한을 부여합니다.

6. 웹 응용 프로그램은 사용자의 브라우저에 응답을 반환합니다.

그림 SSO_Response_Screen.jpg 설명

결론

다양한 흐름에서 볼 수 있듯이 통합 배치에서 가장 좋은 방법은 SSO 서버에 필요한 것으로 간주될 때 런타임 시 SSO 서버에 의해 통합 SSO가 트리거되도록 하는 것입니다. 다른 경우에는 정적 접근 방식을 사용하므로 통합 SSO 흐름이 필요하지 않고(예: 사용자에게 이미 적합한 세션이 있는 경우) 불필요한 통합 작업에 영향을 미치는 경우에도 항상 통합 SSO 흐름을 실행합니다.

• 서버 성능(CPU, LDAP/RDBMS 상호 작용...)

• 관련된 재지정으로 통합 SSO 작업을 수행하는 데 걸리는 시간을 기반으로 하는 사용자의 응답 시간입니다.

추가 학습 자원

docs.oracle.com/learn의 다른 실습을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 접근할 수 있습니다. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer로 전환할 수 있습니다.

제품 설명서는 Oracle Help Center를 참조하십시오.

---

제목 및 저작권 정보

SP vs IdP Initiated SSO

F60244-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.