중앙 승인 서버 구성
중앙 승인 서버 구성
중앙 승인 서버(CAS)는 SSO 프레임워크에 참여하는 PTC 제품 간의 신뢰 관계를 관리합니다. CAS는 사용자 로그인을 승인하고, 사용자가 인증된 후 서비스 공급자와 리소스 서버 간에 교환되는 액세스 토큰을 발급 및 검증하여 응용 프로그램 간에 중개자 역할을 수행합니다.
다음은 CAS를 배포할 때 고려해야 할 몇 가지 일반 팁입니다.
사용자 로그인 세션이 유효한 최대 시간을 검토하고 SSO 솔루션에 참여하는 각 응용 프로그램에서 동일한 값을 사용해야 하는지 여부를 고려합니다.
시스템이 적합한 스큐 공차 시간 내에서 작동하는지 확인합니다. 하나 이상의 시스템 클럭이 CAS와 동기화되지 않고 시스템에 설정된 스큐 공차 시간을 초과하는 경우 구성에서 오류가 발생하고 사용자가 인증되지 않습니다.
PTC SSO가 설정된 제품은 SSO 프레임워크 및 표준 프로토콜을 사용하여 다음 두 가지 인증 흐름을 구현합니다.
페더레이션 인증
승인 - OAuth 권한 부여 유형을 사용하는 위임된 승인
페더레이션 인증
페더레이션 인증은 사용자의 로그인 요청을 ID 공급자에 저장된 자격 증명과 비교하여 검증하는 프로세스입니다.
PTC 제품 SSO 아키텍처에서는 사용자 로그인 요청을 엔터프라이즈 IdP로 리디렉션하도록 중앙 승인 서버(CAS)를 구성해야 합니다. IdP는 사용자 로그인 자격 증명의 유효성을 확인하고 사용자가 인증되었음을 나타내는 어설션을 생성합니다. 인증은 PTC 제품에 지원되는 프로토콜(PTC 제품에 지원되는 SSO 프로토콜 참조) 및 고객 구성에 따라 SAML 또는 OIDC를 사용하여 구현됩니다.
인증이 확인되면 어설션이 요청하는 응용 프로그램에 전송되어 사용자가 성공적으로 인증되었음을 나타내고 사용자 로그인에 대한 권한을 부여합니다. 이 트랜잭션 전체에서 CAS와 PTC 응용 프로그램은 사용자 자격 증명을 볼 수 없으며 이를 관리하지도 않습니다. 브라우저가 IdP로 리디렉션되는 경우 사용자 이름 및 암호 정보 교환은 사용자 클라이언트 에이전트(브라우저)와 IdP 간에 직접 발생합니다. 동일한 CAS를 통해 사용자 인증을 수행하는 동일한 페더레이션에 있는 각 PTC 제품에 대해 별도의 서비스 공급자(SP) 연결을 생성해야 합니다.
SSO 구성에 따라 표준 SAML 및 OIDC 인증 흐름이 적용됩니다. PTC SSO 구성에 사용할 특정 CAS 기술을 선택하기 전에 해당 기술에서 지원하는 옵션을 검토해야 합니다.
다음 시퀀스 다이어그램에서는 인증 흐름을 보여줍니다. 이 예에서는 ThingWorx가 SP 역할을 하고 PingFederate가 CAS 역할을 합니다. ThingWorx는 SP와 IdP 간의 인증 교환을 위해 개방형 표준 SAML 2.0 프로토콜을 사용합니다.
SSO 인증 프로세스 예
인증 프로세스는 다음과 같습니다.
1. 사용자가 서비스 공급자에 액세스를 시도합니다.
2. 서비스 공급자는 사용자에 대한 SAML 요청을 생성하고 요청을 CAS로 전송합니다.
3. CAS는 SAML 요청을 IdP로 리디렉션합니다.
4. IdP는 사용자의 자격 증명(예: 사용자 이름 및 암호)을 제공하기 위해 사용자를 인증 페이지로 리디렉션합니다. 사용자가 자격 증명을 입력하면 IdP에서 SAML 응답을 생성합니다. 사용자가 성공적으로 인증되면 사용자의 승인을 포함하는 SAML 어설션이 SAML 응답에 포함됩니다.
5. 그런 다음 IdP는 응답을 CAS로 리디렉션합니다.
PingFederate의 경우 PTC는 PingFederate를 IdP로 구성하기 위한 자동화 스크립트를 제공합니다. 자세한 내용은 중앙 승인 서버로 PingFederate를 자동으로 구성을 참조하십시오.
타사 IdP의 경우 SSO 설정에서 CAS를 구성해야 합니다.
위임된 승인(OAuth)
위임된 승인은 사용자가 자격 증명을 리소스 서버(RS)와 직접 공유하지 않고도, 서비스 공급자(SP)가 사용자를 대신하여 RS의 리소스에 액세스하거나 작업을 수행할 수 있도록 허용하는 개념입니다.
OAuth 2 액세스 토큰은 CAS에서 요청되며, 이후 이 토큰은 리소스 서버로부터 데이터를 요청할 때 사용됩니다. 리소스 서버는 액세스 토큰을 할당하기 전에 CAS를 통해 요청자가 인증된 사용자인지 확인합니다. 위임된 승인 시나리오에 참여하는 각 PTC 응용 프로그램에 대해 별도의 OAuth 클라이언트를 생성해야 합니다.
PTC 제품은 추가 보호 조치로 범위를 구성하여 OAuth로 보호되는 리소스를 추가 보호합니다. 서비스 공급자가 리소스 서버의 데이터에 대한 요청과 함께 액세스 토큰을 전송하는 경우 액세스 토큰에는 리소스 서버의 데이터에 대해 등록된 범위도 첨부되어 있어야 합니다. 자세한 내용은 위임된 승인의 범위 관리를 참조하십시오.
PTC 제품은 대화형 및 비대화형 클라이언트 모두에 대해 OAuth 권한 부여 유형을 지원합니다. 적절한 권한 부여 유형을 결정하려면 클라이언트 기능을 이해하는 것이 중요합니다.
* 
특정 PTC 제품 설명서를 확인하여 해당 제품에서 지원하는 OAuth 권한 부여 유형을 확인하십시오.
대화형: 사용자가 클라이언트에 인증하면 클라이언트가 동일한 사용자를 대신하여 리소스를 요청합니다. 리소스에 대한 액세스를 허용하는 승인은 최종 사용자 승인을 기반으로 합니다.
비대화형: M2M(사물지능통신) 상호 작용이라고도 합니다. 클라이언트는 응용 프로그램이며 OAuth 토큰을 요청할 때 CAS에 자신을 식별해야 합니다. OAuth 토큰의 ID는 시스템 ID(클라이언트 또는 서비스 사용자)이며 인간 사용자가 아닙니다.
다음 시퀀스 다이어그램에서는 OAuth 승인 코드 흐름을 보여줍니다. ThingWorx는 SP, PingFederate는 CAS, Windchill는 RS입니다. ThingWorx는 개방형 표준 OAuth2 프로토콜 승인 코드 흐름을 사용하도록 구성된 대화형 클라이언트로, SP가 안전하고 신뢰할 수 있으며 효율적인 방식으로 리소스에 액세스할 수 있도록 권한을 부여합니다. 이때 리소스를 검색하기 위한 승인은 최종 사용자의 사용자 ID를 사용하여 수행됩니다.
SSO 승인 프로세스 예
승인 프로세스는 다음과 같습니다.
1. IdP에서 SAML 응답을 받은 후 CAS는 사용자가 승인할 수 있는 승인 부여 요청 페이지를 보냅니다. CAS는 승인 부여 요청 페이지를 사용하여 OAuth 코드를 생성하는 권한을 부여합니다.
2. 사용자가 액세스 권한을 부여하면 CAS에서 OAuth 승인 코드를 생성합니다. 그러면 CAS가 SAML 응답과 승인 코드를 서비스 공급자로 리디렉션합니다.
3. 서비스 공급자가 OAuth 승인 코드를 받으면 승인 코드를 사용하여 CAS에서 액세스 토큰과 새로 고침 토큰을 요청합니다.
4. CAS는 승인 코드의 유효성을 검사하고 OAuth 액세스 토큰과 새로 고침 토큰을 생성합니다. 그러면 CAS가 두 토큰을 서비스 공급자에게 보냅니다.
5. 리소스 소유자(일반적으로 사용자)는 리소스 서버의 데이터가 필요한 서비스 공급자의 콘텐츠를 요청합니다.
6. 서비스 공급자는 액세스 토큰을 사용하여 리소스 소유자 대신 리소스 서버의 콘텐츠를 요청합니다.
7. 리소스 서버는 CAS를 사용하여 액세스 토큰을 확인합니다.
8. 그러면 리소스 서버가 요청된 콘텐츠를 가져와서 서비스 공급자에게 보냅니다.
9. 콘텐츠를 받은 서비스 공급자는 해당 콘텐츠를 리소스 소유자에게 전달합니다.
대체 CAS 기술은 이 동일한 흐름을 사용하여 구성할 수 있습니다. 특정 구성 단계 및 설정을 고려해야 할 수도 있습니다.
비대화형 사례에서는 클라이언트 자격 증명 흐름을 사용하여 클라이언트 ID와 암호를 CAS에 전달하여 OAuth 토큰을 검색합니다. 그런 다음 OAuth 토큰이 RS로 전달되어 요청된 리소스를 검색합니다. RS는 OAuth 토큰 관리 및 요청 유효성 검사를 위해 클라이언트 자격 증명 권한 부여 유형을 지원하도록 구성되어야 합니다. 다음 시퀀스 다이어그램에서는 Windchill을 RS로 하여 비대화형 클라이언트가 리소스를 요청하는 클라이언트 자격 증명 흐름을 보여줍니다.
SSO 아키텍처를 여러 서비스 공급자 및 여러 리소스 서버와의 페더레이션으로 구성할 수도 있습니다. SP 및 RS 구성은 단일 CAS에서 관리됩니다. 이러한 방식으로 모든 사용자 ID가 페더레이션 간에 공유됩니다. 다음 예에서는 Windchill Navigate가 서비스 공급자이고 Windchill 및 SAP가 리소스 서버입니다.
여러 리소스 서버가 있는 SSO 아키텍처
도움이 되셨나요?