분류 기타

인증 및 권한 부여 : 싱글 사인 인 (SSO) 워크 플로의 핵심

컨텐츠 정보

  • 조회 273 (작성일 )

본문

타사 ID 공급자를 통해 사용자가 싱글 사인온을 즐기고 공급 업체가 가장 잘 제공하는 서비스에 집중할 수 있도록 하는 방법입니다.


엔터프라이즈 수준의 SS0 (Single Sign-On) 기술은 한동안 사용되었습니다. 직원들에게 일상 업무에 사용되는 많은 응용 프로그램 각각에 대해 특별한 로그인 자격 증명을 유지하도록 요구하는 것은 성 가실 뿐만 아니라 비효율적이었습니다.

다행히 LDAPActive Directory와 같은 기술은 사용자가 단일 로그인 환경을 구현하기 위해 하나의 로그인 자격 증명 집합을 유지할 수 있도록 만들었습니다. 모든 응용 프로그램이 기업의 사적인 경계 내에 있는 한 잘 작동했습니다. Salesforce 및 WebEx와 같은 외부 응용 프로그램이 기업에서 일반화됨에 따라 응용 프로그램에 대한 액세스를 허용하는 새로운 방법이 필요했습니다. 해결책은 타사 ID 공급자 간의 통신을 허용하는 새로운 사인온 프로토콜을 사용하는 것이었습니다.


SAML (Security Assertion Markup Language)은 새로운 프로토콜 중 첫 번째 프로토콜 중 하나입니다. OpenID와 마찬가지로 OAuth가 곧 이어졌습니다. 사용자가 외부 애플리케이션에 액세스 할 수 있는 새로운 방법을 제공하는 것 외에도 이러한 프로토콜은 사용자 정보에 대한 액세스 권한을 부여하는 새로운 기술을 만들었습니다.


과거에는 모든 접근 권한이 직접 인증에 의해 부여되었습니다. 사용자가 액세스 권한을 얻기 위해 애플리케이션 양식에 사용자 이름 / 비밀번호 쌍을 직접 입력했습니다. 오늘날 SAML, OAuth 및 OpenID에서 애플리케이션에 대한 액세스는 ID 공급자 (IdP)로 알려진 타사 인증 메커니즘을 사용하여 수행됩니다. 자격 증명 공급자는 사용자를 대신하여 특정 사용자의 정보에 대한 요청 당사자 액세스 권한을 부여 할 수도 있습니다.


이 기사에서는 직접 인증과 타사 인증의 차이점을 살펴 보겠습니다. 또한 타사 인증을 사용하여 ID 공급자에 저장된 사용자 정보에 대한 외부 웹 사이트 액세스 권한을 부여하는 방법에 대해서도 설명합니다.


직접 인증 이해 


직접 인증은 사용자 또는 서비스가 사용자 이름 / 암호 쌍 또는 특수 액세스 토큰을 사용하여 네트워크 또는 도메인에 로그인하는 프로세스입니다. 다중 사용자 시스템이 있는 한 직접 인증이 사용되었습니다.


직접 인증 시나리오에서 사용자 액세스 자격 증명은 일반적으로 자격 증명 된 액세스가 필요한 응용 프로그램 내의 데이터베이스 인 안전한 위치에 저장됩니다. 일반적으로 사용자 이름과 암호 또는 토큰과 같은 자격 증명은 암호화 된 형식으로 저장되므로 악의적 인 공격자가 위반시 악의적 인 목적으로 보안 데이터를 사용하는 것을 방지합니다.


그림 1은 가상 웹 사이트 인 Big Social Network에 대한 직접 인증의 개념적 구현 예를 보여줍니다.


Users authenticate directly to Big Social Network 


그림 1 : 직접 인증에서 사용자는 보안에 민감한 사용자 이름과 암호를 사용하여 웹 사이트에 직접 로그인합니다.


Big Social Network는 소셜 네트워크일뿐만 아니라 자체 인증 제공 업체이기도 합니다. 따라서 Big Social Network의 모든 사용자 이름 및 비밀번호 관리는 Big Social Network의 고유 한 ID 관리 기능을 통해 수행됩니다. 즉, Big Social Network는 자체 ID 공급자입니다.


이러한 ID 공급자 (IdP) 개념은 SAML, OAuth 및 OpenID가 예인 타사 인증을 고려할 때 중요한 개념입니다. ID 공급자는 제 3 자 인증을 가능하게 하므로 인터넷 상의 모든 애플리케이션 또는 서비스가 ID 공급자의 인증 기능을 자체적으로 활용할 수 있도록 합니다.


타사 인증 이해 


위에서 언급했듯이 타사 인증을 사용하면 인터넷상의 모든 응용 프로그램 또는 서비스가 다른 웹 사이트의 인증 서비스를 자체적으로 사용할 수 있습니다. 운영상 이것은 예를 들어 가상 사이트 Bob 's Books와 같은 웹 사이트가 ID 관리를 지원하는 다른 웹 사이트에 대한 액세스 권한을 위임 할 수 있음을 의미합니다.


다시 말해, 사용자에게 사용자 이름과 비밀번호를 등록하도록 요청한 다음 등록과 관련된 모든 것을 관리하는 대신 Bob 's Books는 Big Social Network의 인증 기능을 사용하여 작업을 수행 할 수 있습니다. 그림 2는 워크 플로우를 보여줍니다. 세부 사항은 다음과 같습니다.


Users are authenticated by Big Social Network for access to Bob's Books 

그림 2 : 사용자는 인증을 위해 알려진 타사에 사용자 이름과 암호를 제출합니다.



위의 그림 2는 Bob 's Books가 Big Social Network의 ID 공급자 기능을 사용하여 자체 사이트에 대한 보안 로그인을 지원하는 방법을 보여줍니다. 프로세스의 세부 사항을 논의하기 전에 Bob 's Books에서 Big Social Network를 사용하려면 두 엔티티가 서로에 대해 알아야 한다는 점을 이해하는 것이 중요합니다.


Bob 's Books는 Big Social Network를 사용하여 사용자를 인증하기로 결정했을 때 Big Social Network에 공식적인 요청을 보내 소셜 미디어 사이트의 로그인 기능을 활용할 수 있는 권한을 요청했습니다. (운영 수준에서 Bob 's Books는 Big Social Network 로그인을 지원하는 방법으로 OAuth2를 사용하기로 결정했습니다. 여기에서 OAuth2에 대한 자세한 내용을 읽을 수 있습니다.)


Bob 's Books의 요청을 받으면 Big Social Network는 Bob 's Books가 정품인지 확인하는 작업을 수행했습니다. 일단 확인되면 Big Social Network는 Bob 's Books에 고유 한 방식으로 Big Social Network 로그인 페이지에 액세스하는 프로세스를 Bob 's Books에 제공했습니다. 그리고 Bob 's Books는 Big Social Network 로그인이 성공하면 Big Social Network에 응답 할 수 있는 방법을 제공했습니다. 즉, 제 3 자 인증이 수행되기 전에도 Bob 's Books와 Big Social Network는 서로를 잘 알고 있어야 했습니다.


위의 그림 2에 표시된 타사 인증의 실제 메커니즘은 다음과 같습니다. Mary는 bobsbooks.com으로 이동합니다. 그녀는 Bob 's Books에 알려지지 않았기 때문에 Big Social Network를 사용하여 사이트에 로그인 할 수 있음을 알리는 웹 페이지가 표시됩니다. (그림 2, 설명 선 1) Mary는 "로그인"버튼을 클릭하고 Big Social Network가 나타내는 URL로 리디렉션 됩니다. Big Social Network URL에는 Bob의 책을 식별하는 토큰이 추가됩니다. Big Social Network는 URL을 구문 분석하고 Bob 's Books를 대신하여 요청이 이루어 졌는지 확인한 다음 Mary가 Bob 's Books의 후원 아래 Big Social Network에 로그인 할 수 있는 웹 페이지를 제공합니다. Mary는 사용자 이름과 비밀번호를 입력합니다.


Mary는 Big Social Network를 통해 Bob 's Books를 인증했습니다. 다음 단계는 Big Social Network가 Mary에 대한 정보를 Bob 's Books와 공유하도록 허용하는 것입니다. 여기에서 권한 부여가 시작됩니다.


제 3 자 승인 이해 


권한 부여는 제 3자가 정보에 액세스하거나 다른 엔티티와 관련된 작업을 수행 할 수 있는 권한을 부여하는 프로세스입니다. 제 3 자 승인의 예는 Mary가 Big Social Network에서 Bob 's Books가 Big Social Network 친구의 이메일 주소에 액세스 할 수 있도록 허용하는 것입니다.


이 예에서 권한은 특정 정보를 보는 것으로 제한됩니다. 그러나 다른 작업을 승인 할 수 있는 경우가 있습니다. 예를 들어 Mary는 Big Social Network가 Bob 's Books가 자신의 Big Social Network 담벼락에 게시 할 수 있도록 허용합니다.


아래의 그림 3은 권한 부여를 포함하기 위해 그림 2에서 위에서 설명한 인증 프로세스를 보여줍니다. 아래 그림 3의 설명 선 1은 위의 그림 2의 설명 선 2가 중단 된 부분을 선택합니다. 그러나 승인 프로세스를 진행하기 전에 이전에 공유하지 않았던 중요한 정보를 추가해야 합니다.


Bob 's Books는 Big Social Network를 사용하여 사용자를 인증하기로 결정했을 때 로그인 프로세스의 일부로 Mary에게 친구의 모든 이메일 주소에 대한 액세스 권한을 요청하는 데 동의했습니다. 친구의 이메일 주소에 대한 액세스를 제공하는 것은 인증을 위해 필수가 아닙니다. Mary가 거부 할 수 있는 임의의 요청이지만 여전히 로그인 프로세스의 일부입니다.


세부 사항을 살펴 보겠습니다.


Third-party authentication with authorization to friends' email addresses 

그림 3 : 사용자는 가상 사이트 인 Big Social Network와 같은 제 3 자에게 개인 데이터의 일부 또는 전체를 공유하도록 승인 할 수 있습니다.


위의 그림 3, 설명 선 1에서 Mary는 Bob 's Books에서 Big Social Network로 리디렉션 되어 사용자 이름과 암호를 입력합니다. Big Social Network는 Mary의 자격 증명을 가져와 ID 데이터베이스에 저장된 사용자 이름 및 암호와 비교합니다. 자격 증명이 일치합니다. Big Social Network는 Mary를 알고 Bob 's Books가 Mary의 친구의 이메일 주소에 액세스하기를 원한다는 것을 알고 있기 때문에 Mary가 실제로 Bob 's Books와 이메일 주소를 공유하고 싶은지 묻는 Big Social Network의 웹 페이지가 표시됩니다. (그림 3, 설명 선 2). Mary는 Big Social Network에 이메일 주소를 공유 할 수 있는 권한을 부여합니다. 그런 다음 Big Social Network는 Mary를 다시 Bob 's Books로 리디렉션 합니다. 리디렉션의 일부로 Big Social Network는 Mary가 실제로 Big Social Network에 알려져 있음을 나타내는 Bob 's Books의 URL에 토큰을 삽입합니다. Bob 's Books는 Mary가 웹 사이트에 액세스 할 수 있도록 합니다. (그림 3, 설명 선 3)


Mary의 인증을 확인하는 정보가 Bob 's Books로 다시 전달되는 방식은 사용 된 사인온 기술에 따라 다릅니다. SAML은 한 가지 방식으로, OAuth2는 다른 방식으로, OpenId는 세 번째 방식으로 수행합니다. 어떤 방법을 사용하든 간에 알아야 할 중요한 것은 Bob 's Books가 Mary의 사용자 이름과 암호를 모른다는 것입니다. 보안에 민감한 정보는 ID 공급자 (이 경우 Big Social Network)에 국한됩니다.


Bob 's Books가 Mary에게 도메인에 대한 액세스 권한을 부여하면 수행 할 작업이 하나 더 있습니다. Bob 's Books는 Mary 친구의 이메일 주소를 가져와야 합니다. 이것은 Bob 's Books와 Big Social Network의 뒤에서 이루어집니다.


Big Social Network는 Mary가 친구의 이메일 주소에 대한 Bob 's Books 액세스 권한을 부여했음을 알고 있습니다. 또한 승인 과정에서 교환 되는 데이터의 일부는 Bob 's Books가 Big Social Network에서 Mary의 친구의 이메일 주소를 가져 오는 데 사용할 수 있는 정보입니다. 따라서 Bob 's Books의 백엔드 서버에 있는 인텔리전스는 Big Social Network의 백엔드 서버에 연락하여 Mary의 친구의 이메일 주소를 요청합니다. (그림 3, 설명 선 4). Big Social Network는 요청을 수신하고 Bob 's Books가 이메일 주소를 가질 수 있음을 내부적으로 확인하고 전송합니다. (그림 3, 설명 선 5)


사인온 및 인증 프로세스가 완료되었습니다.


함께 모아서 


제 3자를 사용하여 사용자를 인증 한 다음 해당 사용자의 개인 데이터에 액세스 할 수 있는 권한 부여를 촉진하는 것은 인터넷에서 전자 상거래의 성장을 촉진 한 강력한 아키텍처 기술입니다. (아래 그림 4 참조)


New York Times and Ebay offering third-party authentication 

그림 4 : 싱글 사인온 및 타사 인증은 엔터프라이즈 수준 전자 상거래의 일반적인 기능입니다.


도메인 간 싱글 사인온은 사용자 자격 증명 관리의 노동력을 크게 줄여 주므로 웹 사이트와 서비스 제공 업체가 핵심 비즈니스 기능에 집중하고 보안 관리의 평범하지만 중요한 작업을 이러한 작업을 처리하는 데 더 적합한 ID 제공 업체에 맡길 수 있습니다.


이 기사에서는 타사 인증을 사용하여 싱글 사인온을 구현하는 데 필요한 기본 개념을 다뤘습니다. 또한 사용자를 대신하여 인증을 구현하기 위해 싱글 사인온을 확장하는 방법도 다루었습니다. 물론 악마는 항상 세부 사항에 있습니다. SAML, OAuth 및 OpenID와 같은 싱글 사인온 프로토콜에는 각각 특정 작업 방식이 있습니다. 이 기사에 소개 된 개념이 선택한 싱글 사인온 기술의 세부 사항을 마스터하는 데 필요한 시간을 줄이는 견고한 토대를 제공하기를 바랍니다.


https://www.redhat.com/architect/authentication-and-authorization



SSO