PHP 싱글 사인온 문제

Single Sign-On을 했는데 문제가 발생했습니다. 예를 들어 A, B, C 세 개의 시스템이 있습니다. 로그인이 없으면 S 시스템으로 점프하여 로그인합니다. 성공하면 토큰이 생성되고 토큰이 다시 돌아오면 토큰이 Redis에 저장됩니다. 하지만 시스템 B와 C는 어떻게 해당 토큰을 얻습니까?

답글 내용:

Single Sign-On을 했는데 문제가 발생했습니다. 예를 들어 A, B, C 세 개의 시스템이 있습니다. 로그인이 없으면 S 시스템으로 점프하여 로그인합니다. 성공하면 토큰이 생성되고 토큰이 다시 돌아오면 토큰이 Redis에 저장됩니다. 하지만 시스템 B와 C는 어떻게 해당 토큰을 얻습니까?

이 token를 얻은 후 curl 또는 header를 사용하여 인터페이스 또는 GET은 전송된 POST 매개변수를 받아 토큰 값을 처리합니다. 예를 들어 redis, 세션 등에 토큰 값을 저장합니다.token

이제

에 입금하셨으니 B와 C를 redis에 연결하신 후 redisredis에서 직접 출금하시면 안 될까요?

현재 최선의 답변에 반대합니다. 예를 들어 Single Sign-On이 100개의 시스템에 대한 로그인을 담당한다면 각 시스템은 사용자가 로그인한 후 99번을 요청해야 합니까? 싱글 사인온(SSO)이란 또 무엇입니까?

redis에서 직접 토큰을 읽는다고 하시는 분들은 어떤 사용자가 어떤 키를 읽는지 아시나요?

소위 싱글 사인온(Single Sign-On)이란 사용자가 A에 로그인하면 B, C에도 로그인할 수 있는 것이 아니라, S에 로그인하면 A, B에 로그인할 수 있다는 의미입니다. , 및 C.

따라서 두 가지가 필요합니다.

1. S 시스템 자체의 쿠키/세션. 사용자가 S 시스템에 로그인하는 한(S에 직접 액세스하든, A에 로그인하려고 S에 액세스하든) S 시스템에서 사용자가 생성됩니다. 도메인 간 처리가 필요하지 않습니다.

2. 로그인 티켓은 시스템 A에서 왔습니다. 시스템 S는 사용자가 시스템 S에 로그인했는지 확인합니다. 로그인하지 않은 경우 로그인을 요청합니다. 로그인한 후 또는 이미 로그인되어 있습니다. 고유한 티켓이 생성되고 사용자가 로그인됩니다. 사용자와 티켓은 데이터베이스에 저장된 후 티켓이 사용자의 브라우저를 통해 시스템 A로 반환되고 시스템 S에서는 사용자의 브라우저가
. 이때 시스템 A는 티켓을 받고 내부적으로 시스템 S의 검증 인터페이스를 요청한다. 시스템 S는 티켓과 데이터베이스에 있는 티켓을 비교하여 해당 사용자 정보를 찾아 시스템 A로 반환한다. 그러면 시스템 A는 사용자를 알게 된다. 누가 로그인하고 싶어? 누구야? http://AAA.com/login/callback?ticket=xxxxx

피험자가 CAS 프로토콜 https://apereo.github.io/cas/...을 살펴보는 것이 좋습니다

채택된 답변에 반대하는 데에는 여러 가지 이유가 있습니다.

우선 티켓을 발행하고 티켓을 확인하는 과정이 잘못되었습니다. (이 시스템은 일반적으로 단일 지점 장애를 방지하기 위해 이중 머신 핫 백업이 필요하거나 분산됩니다.)
다른 사람들이 말했듯이 100개의 시스템이 의미할 수 있습니까? 그 푸시 100? 타임아웃 등이 발생하면 어떻게 해야 하나요?
한 시스템이 로그아웃되면 다른 시스템도 로그아웃해야 하나요?
권한을 수정하여 로그인 A만 허용하고 로그인 B는 허용하지 않는 경우 , 어떻게 해야 하나요?

도메인 간 문제는 없습니다.

1. a 시스템에 진입하면 s 시스템으로 점프합니다.

2. s 시스템이 계정을 확인한 후 브라우저가 티켓(url 매개변수에 있음)이 있는 a 시스템으로 다시 점프하도록 합니다.

3. 이때 티켓이 a 시스템으로 전달되었습니다.

   시스템은 컬 및 기타 방법을 사용하여 s 시스템에서 티켓을 확인합니다. (또한 자신의 시스템 키를 가져와야 합니다. 이 a 시스템의 검증이 적법하다는 것을 증명하세요.), 인증 티켓인 경우(s 시스템에 로그인했다고 해서 a 시스템에 로그인할 수 있는 것은 아닙니다. 시스템은 발급된 티켓 로그인 권한을 결정한 다음 입력하도록 허용합니다. 그렇지 않으면 시스템 로그인 인터페이스로 돌아갑니다.

저자는 오픈 소스 SSO(Single Sign-On) 시스템의 Java 버전을 배포하여 구체적인 사용법과 프로세스를 알아볼 수 있습니다. OAUTH2.0과 같은 인증 시스템을 개발할 수도 있습니다.

b와 c는 토큰 획득을 위한 인터페이스를 제공합니다. 로그인에 성공하면 재설정하면 됩니다.

저장 및 배송을 위해 쿠키 사용을 고려할 수 있습니다

마스터 스테이션이 로그인을 완료한 후 로그인 서버가 점프백한 후 페이지에 크로스 도메인 코드를 추가하고 동시에 슬레이브 스테이션(또는 다른 사이트)으로 보냅니다. 코드는 다음과 같습니다.

<code><script src=xxxx.com?token=aaaaaa>
</code>

이렇게 하면 xxxx로 토큰을 받아 인증을 진행할 수 있습니다

Single Sign-On을 쉽게 구현할 수 있는 UCenter 또는 OpenCenter를 사용하는 것이 좋습니다

포스터의 의미는 3개 시스템, 크로스 도메인, 세션 ID를 저장하는 방법을 모르겠습니다. 교차 도메인을 달성하기 위해 P3P를 사용하기 위해 UCenter 또는 PHP를 고려할 수 있습니다.

일반적으로 토큰은 일부 암호화 알고리즘 + 솔트를 통해 계산됩니다. B와 C는 토큰을 수신할 때 동일한 암호화 알고리즘을 사용하여 토큰을 확인하면 됩니다.

토큰은 시스템 B, C로 다시 전송되지 않나요? Redis에 직접 연결할 수 있습니다. 표준 포인트는 S 시스템의 특수 인터페이스를 요청하기 위해 매개 변수 또는 헤더에 토큰을 넣는 것입니다.

,,,,,,,,,,