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