PHP에서 싱글 사인온 쿠키 분석 및 구현

Single Sign-On SSO(Single Sign-On)는 ID 관리의 일부입니다. SSO에 대한 보다 일반적인 정의는 다음과 같습니다. SSO는 동일한 서버의 다른 애플리케이션에서 보호된 리소스에 액세스하는 동일한 사용자가 한 번만 로그인하면 된다는 것을 의미합니다. 즉, 한 애플리케이션에서 보안 확인을 통과한 후 보호된 리소스에 액세스할 수 있습니다. 다른 애플리케이션에서는 리소스를 사용할 때 더 이상 확인을 위해 다시 로그인할 필요가 없습니다. 이 기사가 모든 사람에게 도움이 되기를 바랍니다.

SSO란 무엇인가요?

Single Sign-On SSO(Single Sign-On)는 ID 관리의 일부입니다. SSO에 대한 보다 일반적인 정의는 다음과 같습니다. SSO는 동일한 서버의 다른 애플리케이션에서 보호된 리소스에 액세스하는 동일한 사용자가 한 번만 로그인하면 된다는 것을 의미합니다. 즉, 한 애플리케이션에서 보안 확인을 통과한 후 보호된 리소스에 액세스할 수 있습니다. 다른 애플리케이션에서는 리소스에 액세스할 때 확인을 위해 다시 로그인할 필요가 없습니다

SSO 사용:

현재 기업 애플리케이션 환경에는 Taobao, Tmall, Aitaobao 및 기타 제품 및 사무 자동화(OA) 시스템, 재무 관리 시스템, 파일 관리 시스템, 정보 조회 시스템 등 이러한 응용 시스템은 기업의 정보 구축에 도움을 주고 기업에 좋은 이익을 가져다줍니다. 그러나 사용자가 이러한 응용 시스템을 사용하는 것은 불편합니다. 사용자는 시스템을 사용할 때마다 신원 확인을 위해 사용자 이름과 비밀번호를 입력해야 하며, 서로 다른 응용 시스템에는 서로 다른 사용자 계정이 있으므로 사용자는 동시에 여러 세트의 사용자 이름과 비밀번호를 기억해야 합니다. 특히 응용 프로그램 시스템 수가 많고 사용자 수가 많은 기업의 경우 이 문제는 특히 두드러집니다. 문제의 원인은 시스템 개발의 실수가 아니라 전반적인 계획의 부족과 통합된 사용자 로그인 플랫폼입니다. SSO 기술을 사용하면 위의 문제를 해결할 수 있습니다.

SSO의 이점:

사용자를 위한 편의성: 고려하십시오. 실제 사용자 사용 관점에서

응용 시스템 사용 시 사용자는 한 번 로그인하여 여러 번 사용할 수 있습니다. 사용자는 더 이상 매번 사용자 이름과 사용자 비밀번호를 입력할 필요가 없으며 여러 사용자 이름과 사용자 비밀번호 세트를 기억할 필요도 없습니다. Single Sign-On 플랫폼은 애플리케이션 시스템 사용에 대한 사용자 경험을 향상시킬 수 있습니다.
관리자에게 편리함: 일상적인 유지 관리의 관점에서

현재 많은 대형 인터넷 회사에는 많은 애플리케이션이 있습니다. 예를 들어 다음은 Taobao의 스크린샷입니다.

Tmall Juhuasuan 헤드라인 등은 다음과 같습니다. 모두 다름 일부 애플리케이션은 완전히 다른 도메인 이름을 사용하지만 Taobao에 등록된 모든 사용자는 동일한 사용자 이름과 비밀번호 세트를 사용합니다. 이러한 시스템 간에 직접 전환하고 로그인 상태를 동기화할 수 없으면 경험이 매우 저하됩니다. 또 다른 예로, 많은 회사에는 인사 시스템, 재무 시스템, 출석 시스템 등 많은 내부 시스템이 있습니다. 직원이 한 시스템에 로그인하고 다른 시스템으로 이동하기 위해 로그인해야 한다면 매우 불편할 것입니다..

이를 바탕으로 SSO(Single Sign On)가 탄생했습니다. 물론, 이 요구 사항을 실현하는 방법은 여러 가지가 있습니다. 쿠키를 사용하는 것은 해결해야 할 주요 문제입니다. 한 도메인의 쿠키를 다른 응용 프로그램에 알리는 방법. 동일한 애플리케이션에서)?

그래서 쿠키 메커니즘에 익숙하지 않다면 먼저 Google에 검색하여 쿠키가 도메인을 넘지 않도록 설계된 이유 및 기타 관련 문제에 대한 일반적인 이해를 얻으십시오.

시스템 관리자는 편리하고 간단한 통합된 사용자 계정 세트만 유지관리하면 됩니다. 대조적으로, 이전에는 시스템 관리자가 많은 사용자 계정 세트를 관리해야 했습니다. 각 응용 프로그램 시스템에는 일련의 사용자 계정이 있어 관리에 불편을 줄 뿐만 아니라 관리 허점이 생기기 쉽습니다.

응용 시스템 개발 단순화: 응용 프로그램 확장 관점에서 고려

새로운 응용 시스템 개발 시 Single Sign-On 플랫폼의 사용자 인증 서비스를 직접 활용하여 개발 과정을 단순화할 수 있습니다. Single Sign-On 플랫폼은 통합된 인증 플랫폼을 제공하여 Single Sign-On을 구현합니다. 따라서 응용 시스템에서는 사용자 인증 절차를 개발할 필요가 없습니다.
어떻게 달성하나요?

SSO는 다음과 같은 방법으로 구현할 수 있습니다

공유 쿠키

하위 시스템이 모두 상위 도메인 이름 아래에 있으면 브라우저가 동일한 도메인 이름 아래에 있도록 상위 도메인 아래에 쿠키를 심을 수 있습니다. 쿠키를 공유함으로써 쿠키 암호화 및 복호화 알고리즘을 통해 사용자의 Session ID를 획득하여 SSO를 실현할 수 있습니다.

그러나 나중에 이 방법에는 몇 가지 단점이 있다는 사실이 밝혀졌습니다.
a. 동일한 도메인 이름을 가진 모든 시스템은 수정하기 쉽고 안전하지 않은 SessionID를 얻을 수 있습니다.
b.

티켓 확인, 현재 이 접근 방식을 채택하고 있습니다

이 SSO 구현 단계는 다음과 같습니다.

a. 사용자가 로그인되어 있지 않으면 SSO 로그인 페이지로 이동하게 됩니다.
b SSO가 이미 로그인되어 있는지 확인합니다. , 콜백 주소로 직접 점프하고 인증 티켓으로 돌아갑니다.
d. 로그인하지 않은 경우 사용자가 사용자 이름/비밀번호를 올바르게 입력하면 인증이 통과되어 콜백 주소로 점프하고 인증 티켓이 반환됩니다. 서브시스템은 티켓을 획득하고, SSO를 호출하여 사용자 uid 및 기타 정보를 획득하고, 성공 후 사용자 로그인을 허용합니다.

앞서 언급했듯이 쿠키를 통해 SSO를 구현하는 방법은 주로 도메인 간 문제를 해결하는 방법입니다. 먼저 Set-Cookie의 도메인 속성에 대해 이야기해 보겠습니다.

쿠키 도메인

Http 프로토콜이 컨텍스트를 어느 정도 유지할 수 있도록 서버는 응답 헤더에 Set-Cookie를 추가하여 클라이언트에 일부 데이터를 쓸 수 있습니다. -쿠키는 이 쿠키가 위치한 도메인을 나타내는 데 사용됩니다.

Chestnut:

www.cookieexm.com을 방문합니다. 서버가 반환 헤더에 Set-Cookie를 추가하고 도메인이 지정되지 않은 경우 이 쿠키의 기본 도메인은 www.cookieexm.com입니다. 즉, 클라이언트는 www.cookieexm.com을 방문할 때만 이 쿠키를 서버에 반환합니다.

도메인을 .cookieexm.com으로 지정하면 클라이언트는 다음 도메인 이름에 액세스할 때 쿠키를 반환할 수 있습니다: www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com.

그래서 우리는 클라이언트가 결국 쿠키의 도메인과 일치한다는 결론을 내립니다. 이를 바탕으로 SSO 로그인을 구현할 수 있습니다.

쿠키에서 주의해야 할 사항

은 http 전용으로 설정되어 있습니다

관련 로그인 자격 증명(예: 티켓 또는 사용자 이름)은 암호화되어야 합니다.

쿠키는 개인 데이터를 저장할 수 없습니다

특정 Solutions

다음 하위 시스템 **.a1.a2 **.b1.b2 **.c1.c2 간에 Single Sign-On을 구현하려면 먼저 특별히 인증 시스템(sso.s1.s2)이 필요하다고 가정합니다. 싱글 로그인의 경우. 시스템이 현재 로그인되어 있지 않다고 가정하면 예를 들어 www.a1.a2를 방문하십시오.

각 단계의 역할을 각각 살펴보십시오.

Request www.a1.a2

www.a1.a2가 수신합니다. 해당 요청에 로그인 쿠키가 있는지 확인하시고, 아직 로그인하지 않으셨다면 SSO 인증센터로 이동하게 됩니다

SSO는 로그인 창을 제공하며, 사용자는 사용자 이름과 비밀번호를 입력하게 됩니다. SSO 시스템은 사용자 이름과 비밀번호를 확인합니다

이 단계가 중요합니다. 로그인에 성공하면 SSO 시스템의 쿠키가 먼저 클라이언트에 배치되고 사용자의 인증 정보가 비즈니스 당사자에게 전달됩니다. 리디렉션을 통해 이 전송은 명백합니다. 일반적으로 암호화된 쿼리 문자열을 통해 쿠키(다른 도메인)를 통해 전달될 수 없습니다.

비즈니스측 인증 시스템은 SSO 인증 정보를 받아 인증을 진행한 후, 인증 결과 쿠키를 .a1.a2에 기록하면 SSO 인증이 완료됩니다.

이전 결론에 따르면 비즈니스 시스템 www.a1 .a2로 리디렉션됩니다. 현재 .a1.a2로 끝나는 모든 비즈니스 시스템은 이 인증된 쿠키를 사용할 수 있습니다

response


참고:

비즈니스 인증 시스템은 그렇지 않을 수도 있습니다. 존재하며 일부는 그다지 민감하지 않습니다. 시스템은 SSO 인증에서 비즈니스 시스템으로 직접 리디렉션하여 SSO 인증 정보를 그곳으로 가져올 수 있습니다.

위의 내용을 계속 진행하세요. 이때 사용자가 아래 그림과 같이 www.b1.b2 애플리케이션에 액세스하면:

www.a1.a2에 액세스하는 것과 다른 점은 더 이상 그럴 필요가 없다는 것입니다. SSO 인증으로 리디렉션 현재 sso.s1.s2에 이미 쿠키가 있으므로 사용자 이름을 다시 입력하고 쿠키 확인을 직접 사용하십시오.

위는 간단한 쿠키 기반 로그인 시스템입니다.

이러한 문제 중 몇 가지를 해결해야 합니다.

대량의 임시 신뢰 데이터를 효율적으로 저장하는 방법정보 전송 프로세스가 변조되는 것을 방지하는 방법 SSO 시스템이 로그인 시스템을 신뢰하고 로그인 시스템
첫 번째 질문의 경우 일반적으로 memcached와 유사한 분산 캐시 솔루션을 사용할 수 있는데, 이는 확장 가능한 데이터 볼륨을 위한 메커니즘을 제공할 수 있을 뿐만 아니라 효율적인 액세스도 제공할 수 있습니다

두 번째 질문의 경우 디지털 서명 방법 일반적으로 디지털 인증서 서명을 통해 또는 md5와 같은 방법을 통해 채택됩니다. 이를 위해서는 SSO 시스템이 로그인 URL을 반환할 때 md5로 확인해야 하는 매개변수를 암호화하고 마지막으로 토큰과 함께 반환해야 합니다. 로그인을 면제해야 하는 시스템은 신뢰 관계를 확인해야 하며, 이 토큰을 SSO 시스템으로 전달해야 하며, SSO 시스템은 토큰 확인을 통해 정보가 수정되었는지 확인할 수 있습니다. 간단히 말해서, 화이트리스트에 있는 시스템만 프로덕션 신뢰 관계를 요청할 수 있으며, 동시에 화이트리스트에 있는 시스템만 로그인에서 제외될 수 있습니다.


관련 권장 사항:

Single Sign-On 원칙 및 간단한 구현

SSO 싱글 사인온의 세 가지 시나리오를 구현하는 방법에 대한 자세한 설명

UCenter 싱글 사인온/동기 로그인/동기 로그아웃 example_PHP 튜토리얼

위 내용은 PHP에서 싱글 사인온 쿠키 분석 및 구현의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!