SSO Single Sign-On의 원리를 설명하는 예

1. http 무상태 프로토콜

　 웹 애플리케이션은 브라우저/서버 아키텍처를 채택하며 http가 통신 프로토콜로 사용됩니다. http는 상태 비저장 프로토콜입니다. 브라우저의 각 요청은 서버에 의해 독립적으로 처리되며 이전 또는 후속 요청과 연결되지 않습니다. 이 프로세스는 아래 그림에 설명되어 있습니다.

이는 또한 모든 사용자가 브라우저를 통해 서버 리소스에 액세스할 수 있음을 의미합니다. 서버의 특정 리소스를 보호하려면 브라우저 요청을 제한해야 하며, 브라우저 요청을 식별하고 합법적인 요청에 응답해야 합니다. 요청을 무시하고 브라우저 요청을 식별하려면 브라우저 요청 상태를 알아야 합니다. http 프로토콜은 상태 비저장이므로 서버와 브라우저가 공동으로 상태를 유지하도록 하세요! 이것이 세션 메커니즘입니다.

2. 세션 메커니즘

브라우저가 서버에 처음 요청하면 서버는 세션을 생성하고 응답의 일부로 세션 ID를 브라우저에 보냅니다. 두 번째 요청에는 세션 ID가 포함됩니다. 서버는 요청에서 세션 ID를 가져와서 동일한 사용자인지 여부를 알 수 있습니다. 첫 번째 요청

서버는 세션 개체를 메모리에 저장합니다. 브라우저는 세션 ID를 어떻게 저장합니까? 두 가지 방법으로 생각할 수 있습니다

1. 요청 매개변수

2. cookie

　 세션 ID를 각 요청의 매개변수로 사용하면 서버가 요청을 받으면 자연스럽게 매개변수를 구문 분석하여 세션 ID를 얻을 수 있습니다. , 그리고 이를 사용하여 동일한 요청에서 나온 것인지 확인합니다. 분명히 이 방법은 신뢰할 수 없습니다. 그런 다음 브라우저가 세션 ID를 자체적으로 유지하도록 하십시오. 쿠키 메커니즘을 사용하여 이를 수행할 때마다 브라우저가 자동으로 세션 ID를 보냅니다. 쿠키는 브라우저가 소량의 데이터를 저장하는 데 사용하는 메커니즘입니다. 데이터는 "키/값" 형식으로 저장됩니다. 브라우저가 http 요청을 보내면 자동으로 쿠키 정보가 첨부됩니다. 또한 쿠키를 구현합니다. Tomcat 서버에 접속하면 서버에서 "JSESSIONID"라는 쿠키를 볼 수 있습니다. 이 쿠키는 Tomcat 세션 메커니즘에 의해 유지되는 세션 ID입니다. 쿠키를 사용한 요청 응답 프로세스는 다음과 같습니다

3. 로그인 상태

로그인 상태는 이해하기 쉽습니다. 브라우저가 처음으로 서버를 요청할 때 서버가 신원을 확인하기 위해 사용자 이름과 비밀번호를 입력해야 한다고 가정합니다. 사용자 이름과 비밀번호를 확인하고 이를 데이터베이스에서 비교합니다. 이는 현재 이 세션을 보유하고 있는 사용자가 합법적인 사용자임을 의미합니다. 따라서 이 세션을 "인증됨" 또는 "로그인"으로 표시해야 합니다. 세션 상태는 당연히 세션 객체에 저장되어야 합니다. Tomcat은 세션 객체에 로그인 상태를 다음과 같이 설정합니다

1HttpSession session = request.getSession() ;사용자가 다시 방문하면 Tomcat은 세션 객체에서 로그인 상태를 확인합니다

2	session.setAttribute("isLogin",true);

1HttpSes 시온 세션 = request.getSession();

　로그인 상태를 구현하는 브라우저 요청 서버 모델은 아래 그림과 같습니다

　보호된 리소스를 요청할 때마다 세션 개체의 로그인 상태를 확인하며 isLogin=true인 세션만 액세스할 수 있습니다. 따라서 로그인 메커니즘이 구현됩니다.

2. 다중 시스템의 복잡성

웹 시스템은 오래 전부터 단일 시스템에서 여러 시스템으로 구성된 애플리케이션 그룹으로 발전해 왔으며, 오늘날에는 너무 많은 시스템에 직면하여 사용자가 하나씩 로그인해야 합니까? 그럼 하나씩 로그아웃해? 아래 그림과 같이

웹 시스템은 단일 시스템에서 여러 시스템으로 구성된 애플리케이션 그룹으로 발전해 왔으며 그 복잡성은 사용자가 아닌 시스템 자체가 부담해야 합니다. 웹 시스템이 내부적으로 아무리 복잡하더라도 사용자에게는 통일된 전체입니다. 즉, 사용자가 웹 시스템의 전체 애플리케이션 그룹에 액세스하는 것은 단일 시스템에 액세스하는 것과 같습니다

.

단일 시스템 로그인 솔루션은 완벽하지만 다중 시스템 애플리케이션 그룹에는 더 이상 적합하지 않습니다. 이유는 무엇입니까?

　단일 시스템 로그인 솔루션의 핵심은 쿠키입니다. 쿠키는 브라우저와 서버 간의 세션 상태를 유지하기 위해 세션 ID를 전달합니다. 그러나 쿠키에는 제한이 있습니다. 이 제한은 쿠키의 도메인(일반적으로 웹사이트의 도메인 이름에 해당)입니다. 브라우저가 http 요청을 보낼 때 모든 쿠키 대신 도메인과 일치하는 쿠키를 자동으로 전달합니다.

이 경우 이론적으로 웹 애플리케이션 그룹에 있는 모든 하위 시스템의 도메인 이름을 "*.baidu.com"과 같은 하나의 최상위 도메인 이름으로 통합한 다음 해당 쿠키를 설정하는 것이 가능한 이유 초기에도 많은 다중 시스템 로그인에서 동일한 도메인 이름으로 쿠키를 공유하는 이 방법을 사용했습니다.

하지만, 가능하다고 해서 좋은 것은 아니기 때문에, 쿠키를 공유하는 방식에는 많은 제약이 따릅니다. 우선, 애플리케이션 그룹의 도메인 이름이 통일되어야 합니다. 둘째, 애플리케이션 그룹의 각 시스템(적어도 웹 서버)에서 사용하는 기술이 동일해야 합니다. 그렇지 않으면 쿠키의 키 값(Tomcat의 경우 JSESSIONID)이 동일해야 합니다. )이 다르면 세션을 유지할 수 없으며 쿠키 공유 방법을 국경을 넘어 구현할 수 없습니다. java, php, .net 시스템과 같은 언어 기술 플랫폼 로그인은 쿠키 자체가 안전하지 않습니다.

따라서 다중 시스템 응용 그룹의 로그인을 구현하기 위해서는 새로운 로그인 방법이 필요합니다. 바로 Single Sign-On

3. Single Sign-On

Single Sign-On이란 무엇인가요? Single Sign-On의 전체 이름은 Single Sign On(이하 SSO)입니다. 다중 시스템 응용 프로그램 그룹에서 한 시스템에 로그인하면 다시 로그인하지 않고도 다른 모든 시스템에서 인증이 가능하다는 의미입니다.

1. 로그인

단일 시스템 로그인과 비교하여 SSO는 인증 센터에서만 사용자 이름, 비밀번호 및 기타 보안 정보를 허용합니다. 로그인 입구를 제공하지 않으며 인증 센터의 간접적인 승인만 허용합니다. 간접 인증은 토큰을 통해 구현됩니다. SSO 인증 센터는 사용자의 사용자 이름과 비밀번호가 올바른지 확인하고 인증 토큰을 생성합니다. 다음 점프 프로세스에서는 인증 토큰이 매개변수로 각 하위 시스템에 전송됩니다. token. 즉, 부분 세션을 생성할 수 있는 권한이 부여됩니다. 부분 세션 로그인 방법은 단일 시스템 로그인 방법과 동일합니다. Single Sign-On의 원리인 이 과정을 다음 그림으로 설명합니다

　다음은 위 그림에 대한 간략한 설명입니다

1. 사용자는 시스템 1의 보호된 리소스에 접근합니다. 시스템 1 사용자가 로그인되어 있지 않은 것을 발견하고 SSO 인증센터로 이동하여 자신의 주소를 매개변수로 사용

2. sso 인증센터는 사용자가 로그인되어 있지 않음을 발견하고 사용자를 로그인 페이지

3. 로 안내합니다. 사용자는 사용자 이름과 비밀번호를 입력하여 로그인 신청서를 제출합니다

4. sso 인증 센터 확인 사용자 정보, 사용자와 SSO 인증 센터 사이에 글로벌 세션이라고 불리는 세션을 생성하는 동시에 인증 토큰을 생성합니다

5. SSO 인증 센터는 토큰을 가지고 초기 요청 주소(시스템 1)로 점프합니다

6. 시스템 1은 토큰을 받고 SSO 인증 센터로 가서 토큰이 유효한지 확인합니다

7. SSO 인증 센터는 토큰을 확인하고 이를 유효한 것으로 반환합니다. 등록 시스템 1

8. 시스템 1은 토큰을 사용하여 사용자와 세션을 생성하고, 이를 부분 세션이라고 하며, 보호된 리소스를 반환합니다.

9. 사용자가 보호된 리소스에 액세스했습니다. 시스템 2

10. 시스템 2는 사용자가 로그인되어 있지 않은 것을 발견하고 SSO 인증 센터로 점프하여 자신의 주소를 파라미터로 사용합니다.

11. SSO 인증 센터는 사용자가 로그인되어 있음을 발견하고 해당 주소로 다시 점프합니다. 시스템 2의 토큰을 첨부합니다

12. 시스템 2는 토큰을 받고 SSO 인증 센터로 가서 토큰이 유효한지 확인합니다

13. SSO 인증 센터는 토큰을 확인하고 유효한 것으로 반환합니다. 등록 시스템. 2

14. 시스템 2는 토큰을 사용하여 생성하고 사용자의 로컬 세션은 보호된 리소스를 반환합니다

사용자가 성공적으로 로그인한 후 SSO 인증 센터 및 각 하위 시스템에서 세션이 설정됩니다. SSO 인증 센터를 사용하는 사용자를 글로벌 세션이라고 합니다. 사용자가 각 하위 시스템에 설정한 세션을 로컬 세션이라고 합니다. 로컬 세션이 설정된 후에는 하위 시스템의 보호된 리소스에 대한 사용자의 액세스가 더 이상 이루어지지 않습니다. SSO 인증센터를 통해 글로벌 세션과 로컬 세션은 다음과 같은 제약관계를 가지고 있습니다

1. 로컬 세션이 존재하며, 글로벌 세션이 반드시 존재해야 합니다

2. 글로벌 세션은 존재하지만, 로컬 세션은 반드시 존재하는 것은 아닙니다.

3. 글로벌 세션이 소멸되고, 로컬 세션도 소멸되어야 합니다

Blog Park, Baidu, csdn, Taobao 등 웹 사이트의 로그인 프로세스를 통해 Single Sign-On에 대한 이해를 심화시킬 수 있습니다. 로그인 과정에서 점프 URL과 매개변수에 주의하세요

2. 로그아웃

싱글 로그인에는 당연히 싱글 로그아웃도 필요합니다. 하위 시스템에서 로그아웃하면 모든 하위 시스템의 세션이 삭제됩니다. 다음 그림은 설명

SSO 인증 센터에서는 글로벌 세션의 상태를 모니터링하고 있습니다. 글로벌 세션이 파괴되면 리스너는 등록된 모든 시스템에 로그아웃 작업을 수행하도록 알립니다.

다음은 이에 대한 간략한 설명입니다. 위 그림

1. 사용자가 시스템 1에 대한 로그아웃 요청

2. 시스템 1은 사용자가 설정한 세션 ID를 기반으로 토큰을 가져오고 시스템 1은 SSO 인증 센터에 로그아웃 요청을 시작합니다

3. SSO 인증 센터는 토큰이 유효한지 확인하고 글로벌 세션을 파기하며 이를 사용하는 모든 사용자를 제거합니다. 토큰 등록의 시스템 주소

4. sso 인증 센터는 모든 등록 시스템에 로그아웃 요청을 시작합니다

5. 각 등록 시스템은 SSO 인증 센터로부터 로그아웃 요청을 수신하고 로컬 세션을 파괴합니다

6. sso 인증 센터는 사용자를 로그인 페이지로 안내합니다

IV. 배포 다이어그램

싱글 사인온에는 SSO 인증 센터와 많은 하위 시스템과 SSO 인증 센터는 토큰을 교환하고, 토큰을 확인하고, 로그아웃 요청을 시작하기 위해 통신해야 하므로 하위 시스템은 SSO를 통합해야 합니다. SSO 인증 센터는 기본적으로 전체 SSO 서버입니다. SSO 클라이언트와 서버 간의 통신 프로세스 다음 그림을 사용하여 SSO 인증 센터와 SSO 클라이언트 간의 통신 방법을 설명합니다. 여기서는 간단하고 사용하기 쉬운 웹 서비스인 rpc를 예로 들어 보겠습니다. , Restful API를 모두 사용할 수 있습니다. 5. 구현 직접 구현할 수 있습니다. sso는 클라이언트/서버 아키텍처를 채택합니다. 먼저 sso-client와 sso-server가 구현하는 기능을 살펴보겠습니다. (아래: sso 인증 센터 = sso-server)

　 sso-client

로그인되지 않은 하위 시스템을 차단합니다. 사용자 요청, SSO 인증센터로 이동

SSO 인증센터에서 보낸 토큰을 받아 저장

1. SSO 서버와 통신하여 토큰의 유효성을 확인

2. 로컬 세션 설정

   SSO 인증 센터에서 SSO 인증 센터에 로그 아웃 요청을 보내기 사용자 로그 아웃 요청, SSO 인증 센터에서 로그 아웃 요청을 보내고 로컬 세션 파괴

3. SSO- 서버 사용자의 로그인 정보를 검색합니다. 글로벌 세션 + 모든 세션에서 로그아웃

4. 다음은 원칙에 따라 SSO를 단계별로 구현해보겠습니다!

1. sso-client는 비로그인 요청을 차단합니다

5. 　Java는 서블릿, 필터, 리스너의 세 가지 방법으로 요청을 차단합니다. sso-client에서 새 LoginFilter.java 클래스를 생성하고 필터 인터페이스를 구현하고 doFilter() 메서드

1

2

3

1. 4

5

2. 에 로그인되지 않은 사용자 차단을 추가합니다. 6

7

3. 8

9

4. 10

11

5. 12

6. public void doFilter(ServletRequest 요청, ServletResponse 응답, FilterChain 체인)에서 IOException, ServletException {

letRequest req = (HttpServletRequest) 요청 ;

7.  HttpServletResponse res = (HttpServletResponse) 응답;

   HttpSession 세션 = req.getSession();

   if(session.getAttribute("isLogin")) {

   chain.doFilter(request, response);

   return;

   }

     //다음으로 이동 SSO 인증 센터

   res.sendRedirect("sso-server-url-with-system-url");

   }

2	session.getAttribute("isLogin");

2. sso-server는 비로그인 요청을 차단합니다

client Sso 인증 센터의 비로그인 요청으로 점프하여 로그인 페이지로 점프합니다. 이 과정은 sso-client

3과 완전히 동일합니다. sso-server는 사용자 로그인 정보를 확인합니다

사용자가 사용자 이름과 비밀번호를 입력합니다. 로그인 페이지에서 로그인을 요청합니다. 인증에 성공하면 세션 상태가 "로그인됨"으로 표시됩니다.

56

@RequestMapping( "/login") public String login(String 사용자 이름, 문자열 비밀번호, HttpServletRequest req) { this.checkLoginInfo(사용자 이름, 비밀번호); req.getSession( ).setAttribute("isLogin",true);       return "success"; }

4. sso-server는 인증 토큰을 생성합니다. 　 인증 토큰은 임의의 문자로 이루어진 문자열입니다. 어떻게 생성되든 반복되지 않고 쉽지만 않다면 그냥 위조하세요. 여기 예시가 있습니다 1

String token = UUID.randomUUID().toString();

5. sso-client가 토큰을 획득하고 확인합니다2

sso 인증 센터에 로그인한 후 하위 시스템으로 돌아가서 토큰을 연결합니다. 확인을 위해 SSO 인증 센터에 연결하고 LoginFilter.java의 doFilter()에 몇 줄을 추가합니다

1

3

4

56

7 8 9 10 11 //요청에 토큰 매개변수가 함께 제공됩니다 String token = req.getParameter("token"); if (token != null) { // 이동 토큰을 검증하기 위한 SSO 인증 센터 booleanverifyResult = this.verify("sso-server-verify-url", token ); if(!verifyResult) {

res.sendRedirect("sso-server-url" ); return; } chain.doFilter(request, response); } 　verify() 메소드는 httpClient를 사용하여 구현됩니다. httpClient는 공식 문서를 참고하세요 1 2

HttpPost httpPost =new HttpPost("sso-server-verify- url-with-token");

HttpResponse httpResponse = httpClient. 실행(httpPost);7. 부분 세션

6. sso-server는 인증 토큰 요청을 수신하고 처리합니다. 사용자가 SSO 인증 센터에 성공적으로 로그인한 후 sso-server는 인증 토큰을 생성하여 저장합니다. , sso-server는 토큰이 존재하는지, 만료되었는지 여부를 확인합니다. 토큰 확인이 성공한 후 sso-server는 시스템이 SSO 인증 센터에 등록된다는 의미입니다.

토큰 및 등록 시스템 주소는 일반적으로 키-값 데이터베이스(예: redis)에 저장됩니다. Redis는 토큰의 유효 기간인 키의 유효 기간을 설정할 수 있습니다. Redis는 메모리에서 실행되며 매우 빠릅니다. sso-server는 데이터를 유지할 필요가 없습니다. 　토큰 및 등록 시스템 주소는 아래 그림에 설명된 구조를 사용하여 Redis에 저장할 수 있습니다. 왜 이러한 시스템의 주소를 저장해야 합니까? 저장되어 있지 않으면 로그아웃 시 문제가 발생합니다. 사용자는 SSO 인증 센터에 로그아웃 요청을 제출하고, SSO 인증 센터는 해당 글로벌 세션을 어떤 시스템에서 사용했는지 알 수 없습니다. 자신의 로컬 세션을 설정하거나 SSO 인증 센터에 보내야 하는 하위 세션이 없습니다. 시스템은 로컬 세션에서 로그아웃하기 위해 로그아웃 요청을 보냅니다

토큰 확인이 성공한 후 sso-client는 현재 부분 세션을 "로그인"으로 표시하고 LoginFilter .java를 수정하고 몇 줄을 추가합니다

1

2

3

if (verifyResult) { session.setAttribute("isLogin",true);

}

　 sso-client는 또한 현재 세션 ID를 토큰에 바인딩해야 하며, 이는 이 세션의 로그인 상태가 토큰과 관련되어 있음을 나타냅니다. 이 관계는 Java 해시맵을 사용하여 저장할 수 있습니다. 저장된 데이터는 전송된 로그아웃 요청을 처리하는 데 사용됩니다.

8. 로그아웃 프로세스

사용자는 하위 시스템에 "로그아웃" 매개변수(로그아웃 요청)를 보냅니다. 이 요청을 가로채고 SSO 인증에 대한 로그아웃 요청을 시작합니다. center

1 2 3 4

String logout = req.getParameter("logout"); if (logout != null) { this.ssoServer.logout (token); }

sso 인증 센터도 동일한 방법을 사용하여 sso-client 요청이 로그아웃 요청("logout" 매개변수 사용)이고 Sso 인증 센터가 로그아웃하는지 식별합니다. 글로벌 세션

1 2 3 4 5 6 7 8

@RequestMapping("/logout") 공개 문자열 로그아웃(HttpServletRequest req) {  HttpSession 세션 = req.getSession(); if(session != null) { session.invalidate();//Trigger LogoutListener } return "redirect:/"; }

SSO 인증 센터에는 글로벌 세션 모니터가 있습니다. 글로벌 세션이 로그아웃되면 등록된 모든 시스템에 로그아웃 알림이 전송됩니다

SSO 싱글 사인온 PHP 구현 방법(Laravel 프레임워크)

1 2 3 4 5 6 7 8

공용 클래스 LogoutListener는 HttpSessionListener를 구현합니다. {                          ~ | 관련 추천: PHP에서 싱글 사인온 쿠키 분석 및 구현 싱글 사인온 원칙 및 간단한 구현

위 내용은 SSO Single Sign-On의 원리를 설명하는 예의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!