싱글 사인온에 CAS 프로토콜 또는 OAuth + 일부 인증 공급자를 사용해야하는지 궁금합니다 .
시나리오 예 :
- 사용자가 보호 된 리소스에 액세스하려고하지만 인증되지 않았습니다.
- 응용 프로그램은 사용자를 SSO 서버로 리디렉션합니다.
- 꿀벌이 인증되면 사용자는 SSO 서버에서 토큰을받습니다.
- SSO는 원래 응용 프로그램으로 리디렉션됩니다.
- 원래 응용 프로그램은 SSO 서버와 비교하여 토큰을 확인합니다.
- 토큰에 문제가 없으면 액세스가 허용되며 응용 프로그램은 사용자 ID를 알고 있습니다.
- 사용자는 로그 아웃을 수행하고 연결된 모든 응용 프로그램에서 동시에 로그 아웃합니다 (싱글 사인 아웃).
내가 이해하는 한 정확히 CAS가 발명 된 것입니다. CAS 클라이언트는 인증 서비스를 사용하기 위해 CAS 프로토콜을 구현해야합니다. 이제 클라이언트 (소비자) 사이트에서 CAS 또는 OAuth를 사용하려고합니다. OAuth가 CAS의 해당 부분을 대체합니까? 새로운 사실상의 표준으로서 OAuth를 선호해야합니까? 사용자 이름 / 암호, OpenID, TLS 인증서 등의 다른 방법을 지원하는 CAS의 인증 부분을 쉽게 사용할 수있는 (Sun OpenSSO가 아님) 대체품이 있습니까?
문맥:
- 다른 응용 프로그램은 SSO 서버의 인증에 의존해야하며 세션과 유사한 것을 사용해야합니다.
- 애플리케이션은 GUI 웹 애플리케이션 또는 (REST) 서비스 일 수 있습니다.
- SSO 서버는 중앙 사용자 정보 저장소에서 역할, 전자 메일 등과 같은 사용자에 대한 추가 정보를 얻는 데 필요한 사용자 ID를 제공해야합니다.
- 싱글 사인 아웃이 가능해야합니다.
- 대부분의 클라이언트는 Java 또는 PHP로 작성되었습니다.
방금 WRAP을 발견 했는데 OAuth 후속 작업이 될 수 있습니다. Microsoft, Google 및 Yahoo에서 지정한 새로운 프로토콜입니다.
추가
나는 OAuth가 SSO를 구현하는 데 사용될 수 있지만 인증을 위해 설계되지 않았지만 OpenID와 같은 SSO 서비스와 함께 사용된다는 것을 알게되었습니다.
OpenID는 “새로운 CAS”인 것 같습니다. CAS에는 싱글 사인 아웃과 같은 OpenID 누락 기능이 있지만 특정 시나리오에서 누락 된 부분을 추가하는 것은 어렵지 않습니다. OpenID는 광범위하게 수용되고 있으며 OpenID를 응용 프로그램이나 응용 프로그램 서버에 통합하는 것이 좋습니다. CAS도 OpenID를 지원한다는 것을 알고 있지만 CAS는 OpenID와 함께 없어야합니다.
답변
OpenID는 CAS의 ‘성공자’또는 ‘대체자’가 아니며 의도와 구현 방식이 다릅니다.
CAS는 인증을 중앙 집중화 합니다. 모든 (아마도 내부의) 응용 프로그램이 사용자에게 단일 서버에 로그인하도록 요청하려면 모든 응용 프로그램이 단일 CAS 서버를 가리 키도록 구성하십시오.
OpenID는 인증을 분산 시킵니다. 애플리케이션이 원하는 인증 서비스에 대한 사용자 로그인을 허용하도록하려면 사용하십시오 (사용자는 OpenID 서버 주소를 제공합니다. 실제로 ‘username’은 서버의 URL입니다).
위의 어느 것도 인증 및 / 또는 사용자 정의없이 권한 부여를 처리하지 않습니다.
OAuth는 권한 부여를 처리하지만 기존 ‘USER_ROLES 테이블'(사용자 액세스)을 대체하지 않습니다. 타사의 인증을 처리합니다.
예를 들어 응용 프로그램을 Twitter와 통합하려는 경우 사용자가 데이터를 업데이트하거나 새 콘텐츠를 게시 할 때 자동으로 트윗하도록 허용 할 수 있습니다. 암호를 얻지 않고 사용자를 대신하여 일부 타사 서비스 또는 리소스에 액세스하려고합니다 (사용자에게는 안전하지 않음). 애플리케이션이 Twitter에 액세스를 요청하고 사용자 가 Twitter를 통해 승인 한 다음 앱에 액세스 할 수 있습니다.
따라서 OAuth는 Single Sign-On (CAS 프로토콜 대신 사용)에 관한 것이 아닙니다. 그것은 약없는 당신이 사용자가 액세스 할 수있는 제어. 그것은시키는에 관한 사용자 방법을 제어하기 위해 자신의 자원이 타사에 액세스 할 수 있습니다. 매우 다른 두 가지 사용 사례.
설명한 맥락에서 CAS가 올바른 선택 일 수 있습니다.
[업데이트 됨]
즉, 사용자 ID를 보안 리소스로 간주하면 OAuth를 사용하여 SSO를 구현할 수 있습니다. 이것이 기본적으로 ‘깃 허브 (GitHub)에 가입’하는 것과 같은 것입니다. 프로토콜의 원래 의도는 아니지만 가능합니다. OAuth 서버를 제어하고 앱만 인증하도록 앱을 제한하면 SSO입니다.
그러나 로그 아웃을 강제로 수행하는 표준 방법은 없습니다 (CAS에는이 기능이 있습니다).
답변
나는 이런 식으로 생각하는 경향이 있습니다.
사용자 인증 시스템을 제어 / 소유하고 중앙 집중식 인증이 필요한 이기종 서버 및 앱 세트를 지원해야하는 경우 CAS를 사용하십시오.
소유 / 지원하지 않는 시스템 (예 : Google, Facebook 등)에서 사용자 인증을 지원하려면 OAuth를 사용하십시오.
답변
OpenID 는 인증 프로토콜이고 OAuth 및 OAuth WRAP 는 인증 프로토콜입니다. 그것들은 하이브리드 OpenID 확장 과 결합 될 수 있습니다 .
나는 사람들이 현재 응용 프로그램에 정확히 맞지 않더라도 많은 추진력 (더 많은 지원, 더 쉽게 참여할 수있는)을 가진 표준을 기반으로 구축하는 것을 선호합니다. 이 경우 OAuth에는 CAS가 아닌 추진력이 있습니다. OAuth와 관련하여 필요한 모든 작업을 수행 할 수 있어야합니다. 차후에 OAuth WRAP는 일을 더 단순화해야합니다 (베어러 토큰을 사용하고 프로토콜 계층으로 암호화를 푸시함으로써 가치있는 트레이드 오프를 만들어야 함). 그러나 아직 초기 단계에 있습니다. 아마 일을 잘 할 것입니다.
궁극적으로 OpenID 및 OAuth를 사용하기로 선택하면 더 많은 언어의 라이브러리를 사용할 수 있으며 시스템과 통합해야하는 다른 사람도 사용할 수 있습니다. 또한 프로토콜을 살펴보면 훨씬 더 많은 안구가 있으므로 실제로 예상보다 안전합니다.
답변
구현 분명히 OAuth를하는 서버가 있기 때문에 나에게, SSO와의 OAuth 사이의 진정한 차이는 부여하지 인증은 이 인증을 (당신의 OAuth 클라이언트 응용 프로그램과 함께 일하기 위해 구글, 오픈 아이디 또는 페이스 북에 로그인 할 수 있습니다)
SSO에서 고급 사용자 / sysadmin은 “SSO 앱”에서 미리 응용 프로그램에 대한 최종 사용자 액세스 권한을 부여합니다. OAuth에서 최종 사용자는 “OAuth 앱”의 “데이터”에 대한 응용 프로그램 액세스 권한을 부여합니다.
OAuth 프로토콜을 SSO 서버의 일부로 사용할 수없는 이유를 알 수 없습니다. 플로우에서 권한 부여 화면을 꺼내고 OAuth 서버가 지원 데이터베이스에서 권한 부여를 찾도록하십시오.
답변
이전 게시물이지만 유용 할 수 있습니다.
CAS 3.5는 oAuth를 클라이언트 및 서버로 지원합니다. 참조 : https://wiki.jasig.org/display/CASUM/OAuth
답변
