위임된 승인의 범위 관리
위임된 승인의 범위를 사용하면 사용자 계정에 대한 응용 프로그램의 액세스를 제한할 수 있습니다. 범위는 리소스 서버 내의 데이터에 대한 추가 액세스 보호 계층을 제공하는 문자열 값으로 OAuth 액세스 토큰과 함께 제공될 수 있습니다.
범위 이름(문자열 값)을 리소스 서버의 데이터와 쌍으로 지정한 다음 중앙 승인 서버 및 서비스 공급자에 범위를 등록합니다. 서비스 공급자가 리소스 서버로부터 데이터를 요청하는 경우 유효한 액세스 토큰을 제공하고 리소스 서버의 데이터와 연관된 범위에 대한 승인이 있어야 합니다.
다음 프로세스에서는 범위가 작동하는 방식을 보여줍니다.
1. 사용자가 서비스 공급자에 로그인하면, 중앙 승인 서버는 사용자가 IdP로 인증되었을 때 사용자 로그인 세션을 승인합니다.
2. 그런 다음 중앙 승인 서버는 승인 부여 페이지를 사용자에게 표시합니다.
승인 부여 페이지에는 서비스 공급자가 사용할 수 있는 범위와 연관된 리소스가 나열됩니다.
3. 사용자는 서비스 공급자에게 리소스 서버의 데이터에 대한 액세스를 전체 허용할지 또는 일부만 허용할지 여부를 결정합니다.
4. 승인된 경우 중앙 승인 서버는 서비스 공급자에 액세스 토큰을 제공하고 해당 범위에 대한 승인 부여를 기록합니다.
5. 서비스 공급자가 리소스 서버를 호출하고 보호된 데이터를 요청하면 액세스 토큰이 전송됩니다.
6. 리소스 서버는 중앙 승인 서버를 사용하여 액세스 토큰을 확인합니다. 이 토큰이 유효하고 사용자가 보호된 리소스와 쌍을 이루는 범위에 대한 SP 승인을 받았음을 AS가 확인하면 리소스 서버가 데이터에 대한 액세스 권한을 부여합니다.
다음 순서로 SSO 프레임워크에서 세 개 이상의 응용 프로그램에 있는 범위를 등록해야 합니다.
1. 두 응용 프로그램 간의 신뢰 관계를 관리하는 중앙 승인 서버(PingFederate)
중앙 승인 서버 관리자는 중앙 승인 서버에 등록된 범위를 확인하고 리소스 서버 및 서비스 공급자 응용 프로그램 관리자와 범위 등록을 조정해야 합니다.
PingFederate에서 범위를 등록하는 방법에 대한 자세한 내용은 해당 PingFederate 설명서를 참조하십시오.
2. 데이터가 있는 리소스 서버
리소스 서버에서 범위를 만드는 제품 관리자와의 협력이 필요합니다.
3. 데이터를 요청하는 서비스 공급자
중앙 승인 서버 및 리소스 서버에 등록된 범위의 하위 집합을 등록하도록 선택할 수 있습니다. 제품 관리자 또는 응용 프로그램 개발자와 협력하여 서비스 공급자가 사용할 수 있는 범위를 등록합니다.
 |
응용 프로그램에 등록된 범위 이름은 중앙 승인 서버에 등록된 범위와 일치해야 합니다. 그렇지 않으면 응용 프로그램에서 중앙 승인 서버를 통해 인증을 라우팅하는 경우 관리자 계정을 포함하여 사용자 잠금이 발생할 수 있습니다. 응용 프로그램의 범위가 잘못되었거나(대/소문자 구분 포함) 이를 중앙 승인 서버에 등록하지 않은 경우 관리자가 로그인을 시도할 때 중앙 승인 서버에서 인증되지 않을 수 있습니다. 서비스 공급자에 등록된 범위가 승인 서버에 없는 경우 사용자가 로그인할 수 없습니다(관리자 계정 포함).
이 문제를 해결하려면 SP 관리자가 로그인할 수 있도록 승인 서버에 잘못된 범위 또는 추가 범위를 추가합니다. 그런 다음 문제가 되는 범위를 SP에서 제거하고 승인 서버에서 범위를 삭제합니다.
|
모범 사례 및 보안 고려 사항
◦ SSO 배포의 범위에 대한 사용 정책을 설정할 때는 조직의 보안 전문가에게 문의하십시오. 범위가 등록되거나 구성된 배포의 각 응용 프로그램 내에서 교환 중인 데이터에 대한 보안을 강화하기 위한 단계를 수행할 수 있습니다. 예를 들어, 리소스 서버 내에서 여러 범위를 지정하여 별도의 데이터 집합을 관리하고 보다 정확한 제어를 제공할 수 있습니다.
◦ 범위 관리에 대한 고급 보안 구성은 PingFederate 제품 설명서를 참조하십시오. 예를 들어, 별도의 액세스 토큰과 연관되도록 범위를 구성합니다.
◦ 범위 보안에 대한 OAuth 업계 모범 사례를 참조하십시오. 자세한 내용은 OAuth 2.0 Threat Model and Security Considerations(OAuth 2.0 위협 모델 및 보안 고려 사항)를 참조하십시오.